CMMI, CSMM, ITSS, DCMM: Which One Does Your Tender Ask For?

Bottom line: CMMI, CSMM, ITSS, DCMM and DSMM often end up on the same "do we need it?" list, yet they sit in three separate directions — development process (CMMI, CSMM), IT service (ITSS) and data (DCMM, DSMM). Pick the wrong direction and no grade will match the tender; pick the right direction and the next question is which certificate inside it. So selection does not start with comparing how much weight each one carries — it starts with opening the tender document to see whether it wants "how your software is developed", "how your service is delivered", or "how your data is managed and protected". Those three sentences are the three directions, and none of them stands in for another.

The second point to settle early: inside one direction there are often two routes, and you do not have to walk both. CMMI and CSMM look at similar things, ITSS and ISO 20000 complement each other, DCMM and DSMM are the "managed well" and "held secure" sides of the same data estate. The common waste is not too few certificates — it is repeat investment inside one direction while another direction is missing the single certificate that a scoring item blocks.

First, level the frame. The table below covers positioning only — not fees, not timelines; those depend on company size, assessment scope and the body's determination, and no table can give a general answer.

Using the table is simple: read down for the row that appears in your tender, rather than picking from the bottom the one that sounds advanced. The "typical tender scenario" column is an empirical grouping — it says "typical", not "always"; on every bid, the tender document itself governs.

1. Separate the three directions first, then choose the certificate

Why fix the direction first? Because these three things answer three different questions, and they do not assess the same object at all.

• Development process capability asks: given a requirement and a schedule, can you build it reliably, and is the quality of what you build predictable? It looks at the chain of initiation, planning, requirements, design, review, testing, configuration and measurement.
• IT service capability asks: once the system is live, can you operate it to the level you promised? It looks at the service catalogue, response and recovery, incident and problem, change and release, service level and continual improvement.
• Data management and data security asks: does anyone own your data, and to what degree is it managed; can sensitive data flow to places it should not reach? It looks at whether the data standards, quality, architecture, application and security domains actually run.

Inside a company these three chains belong to different people, and when something goes wrong, different people carry the responsibility. So they cannot substitute for each other in an assessment — a team that delivers projects on time does not necessarily run operations to a stable SLA, and a company with fine-grained data governance does not necessarily have a measurable development process. That is not a defect of the assessment frameworks; the capabilities simply do not sit on the same plane.

There is a crude but effective way to tell which direction a tender wants: look at what material it asks you to submit. Process documents, organisation-level process assets and project measurement data point to development process; a service catalogue, service level records, operations tickets and incident drill records point to IT service; a data catalogue, data quality reports, data classification and security policy point to data. A material list is harder to fake than a certificate name.

2. CMMI and CSMM: two routes in the same direction

CMMI is an international system. It assesses the development and delivery process of software and systems engineering, is graded 1–5, and is carried out by an authorised lead appraiser. Its strength is turning "process" into something that can be inspected: not what you delivered, but whether you have a stable way of working so that different projects and different people do not produce wildly different results.

CSMM is the domestic software capability maturity assessment; its focus is close to CMMI, and its adoption in government projects has grown in recent years. Two words in that sentence need pulling out: "close" is not "equivalent", and "growing adoption" is not "generally mandatory".

So the choice inside this direction turns on three points only:

• Do whichever the tender names. If the tender names CMMI and you bid with CSMM, whether the evaluation accepts it is decided by the evaluation committee under that document — and the reverse holds just the same. The tender document itself governs; there is no room for interpretation here.
• Look at your customer mix. Where customers are mainly international vendors, foreign-invested companies and export-oriented system integrators, CMMI travels better; where customers are mainly domestic government projects and state-owned informatisation, CSMM fits better. Do it the other way round and you hold a certificate you cannot use.
• If you already hold one, do not rush to add the other. Because the focus is close, the organisation-level process assets, project document system and measurement mechanism you built for one can largely be reused for the other. What genuinely needs adding is the difference in assessment rules and in how evidence is organised — not a second process built from zero.

3. ITSS and ISO 20000: complementary, not substitutes

This is a pair that gets asked about a lot. Both point at IT service, but they land in different places: ITSS is the domestic IT service capability assessment, graded, aimed particularly at operations; ISO 20000 is an IT service management system certification that asks whether your service organisation runs in a systematic way.

As an analogy: ISO 20000 is closer to asking "do you have a service management system that keeps itself running" — whether policy, objectives, responsibilities, processes, measurement, internal audit, management review and continual improvement close the loop; ITSS is closer to asking "what level has your service capability reached" — what level of service the combination of personnel, process, technology and resource can support.

Precisely because the angle differs, the industry usually treats them as complementary: the system answers "stable operation over the long term", while the capability grade answers "a level marker that can be compared externally".

• If the tender asks for a service capability grade, look at ITSS;
• If the tender asks for a service management system certification, look at ISO 20000;
• If both requirements appear, you need both, but the build path can be merged — the service catalogue, service levels, incident and problem processes and the continual improvement mechanism are a shared base; build it once and both can be certified on it.

Conversely, one common wrong judgement: assuming that once ISO 20000 is in hand, the ITSS grade requirement is automatically satisfied. The two assess different objects — one a system, one a capability grade — and neither covers the other. To confirm for real there is only one route: take the tender document and check it line by line.

4. DCMM and DSMM: one manages data well, one keeps it secure

In the data direction the line between the two is fairly clear. DCMM is the data management capability maturity model — 5 levels, 8 capability domains — assessing data management capability as a whole: whether data as an asset has a strategy, whether there is a governance mechanism, whether standards and quality are actually managed, whether architecture and application keep pace. DSMM is the data security capability maturity model, focused on data security capability: whether security measures hold through collection, transmission, storage, processing, exchange and destruction.

One line to separate them: DCMM cares whether data is managed well and can be put to use; DSMM cares whether data is held secure and moves according to the rules.

The two can be combined, and combining is common, because they share a set of foundation work: the data asset inventory, data classification and grading, data owners and the management organisation, and mapping how data flows. Once that is done, the professional parts of DCMM and DSMM each have somewhere to land. The difference is where the effort goes afterwards: DCMM moves towards data standards, data quality, data architecture and data application; DSMM moves towards security policy, permissions and masking, audit and monitoring, and security incident handling.

Either order works; it depends on the starting point. Where the governance foundation is thin and you cannot even produce a data catalogue, building towards DCMM first runs smoother; where classification and security assessment have already been done to regulatory requirements, entering through DSMM takes less effort. Which one comes first still depends on the customer and the tender — if the tender names one of them, there is no sequencing question, do that one.

5. Common combinations: choose by business shape, not by certificate count

The logic of combining is not "more certificates is steadier", but letting the certificates cover the business chain you actually run. The four shapes below cover the situation of many companies.

1. Software development and project delivery as the main business

The core combination is one certificate in the development process direction (CMMI or CSMM, decided by the tender and the customer mix). If you also take on data platform or data governance projects, add DCMM as needed; if the deliverables themselves involve customer sensitive data, DSMM is the gap-filler. ITSS is usually not a priority in this type of company — unless you also run operations.

2. IT operations, outsourcing services and system integration

The core is ITSS + ISO 20000. One gives a capability grade, the other gives system backing, and both share the service catalogue and process base — a combination with a reasonable return on effort. If you also hold data for customers or carry security responsibility, add ISO 27001 or a CCRC qualification; that is reinforcement in the security direction and does not conflict with IT service.

3. Data services, data platforms and government data operations

The core is DCMM + DSMM. The first shows you can manage data and put it to use; the second shows you can keep it secure. This combination appears often in data projects, and it is the identity many companies need when moving from "system integrator" to "data service provider".

4. Full-range government and enterprise suppliers

One certificate in each of the three directions is the norm for this type of company: one for development process, one for IT service, one for data. The reminder here is about sequence — do not start all three at the same time. The usual result of running them in parallel is three sets of documents half written and three sets of records too thin, all of them stuck at audit. Rank by the dates in your tenders and take them one at a time; that is the steadier approach.

6. Match your company type

If the logic above still feels abstract, use this table directly. Find yourself in the left column and read the priorities across.

There is deliberately no "size" column. The choice among these five certificates depends hardly at all on headcount; it depends on what you sell, who the customer is and what the tender asks for. A focused twenty-person software company and a two-hundred-person integrator may get exactly opposite answers.

7. Four common misjudgements

• Misjudgement one: assuming CMMI covers ITSS. Development process capability does not imply a grade in operations service capability. In a tender these are usually two separate scoring items, and no evaluator will substitute one for the other. The reverse holds as well: ITSS does not cover CMMI.
• Misjudgement two: assuming DCMM covers DSMM. Managing data well is not the same as keeping it secure. Companies with a sound governance system and high data quality but no permissions, masking, audit or flow monitoring are not rare. And going the other way, security without governance leaves the data still unusable.
• Misjudgement three: assuming that holding the certificate satisfies every tender. The same certificate is written very differently across tenders: some name only the certificate, some state a grade requirement, some require the assessment scope to cover a particular business, some require the certificate to be within its validity period with surveillance audit records attached. Matching the name is only the entry ticket — scope, grade, validity and attachments all have to be checked line by line, and the tender document itself governs throughout.
• Misjudgement four: assuming that a higher grade is safer, and reaching for a high grade straight away. A grade has to be held up by real operating evidence. If the process never actually runs and project data cannot be produced, forcing the grade either stretches the preparation period without limit or lets the system slide straight back after the assessment, which shows plainly at the next surveillance or reassessment. The grade should match the actual level of the business and the threshold in the tender; higher is not automatically better.

There is also a habit that is less a misjudgement than an expensive one: treating selection as a one-off purchasing decision. Certificates have a validity period, they need reassessment at expiry with surveillance in between, and tender requirements shift year by year. Selection should be run once a year against the orders in hand, rather than fixed a few years ago and followed ever since.

8. Scheduling: save on the shared base, not by compressing the assessment

The core scheduling principle is a single line: different directions, one source of evidence. The three directions look far apart, but inside a company they share the same underlying material — organisation structure and responsibility documents, personnel competence and training records, project and service ledgers, operating data inside tools, supplier and outsourcing management files, and the internal audit and management review mechanism. Do this once and several certificates can cite it; do it separately and it is duplicated labour.

In practice, proceed in this order:

1. Fix the directions and the count first, then talk scheduling. Take the tenders and customer requirements you expect over the coming period and separate "must have" from "may need". The must-haves go first, the may-needs are left with an interface in place, and neither starts early without reason.
2. Run one unified capability inventory. A single inventory outputs three things at once: a problem list for the development process, a problem list for the service processes, and a problem list for data and data security. One report can feed the gap analysis for several directions at the same time, instead of each being done separately.
3. Build the shared base. Document and record control, role responsibilities and the competence matrix, the training mechanism, the internal audit and management review mechanism, the supplier management file — these are the common parts of any management system, built once and used by every direction.
4. Keep the professional content separate; do not write it as one blend. Process assets and project documents for the development process, the service catalogue and level management for the service direction, the data catalogue and classification for the data direction — each has its own professional core, and blending them produces something no assessor will recognise at either end.
5. Stagger the assessments and audits. Facing two assessments in the same quarter drains the team and leaves no time to tidy the records. Space the on-site days of the different directions apart, leaving a window for remediation and record catch-up in between; it uses less manpower than running everything in parallel.
6. Move into routine maintenance the moment it is issued. Records are produced month by month, not assembled before an assessment. Embed data collection in day-to-day project closure, ticket closure and data change processes, so that later surveillance and reassessment do not have to stop the business.

One thing needs saying plainly: what scheduling saves is duplicated preparation and duplicated remediation, not the assessment itself. Each direction has its own assessment rules, assessment body and evidence requirements, and none of the procedure can be skipped. Any claim that several certificates can be obtained in "one assessment" deserves a question mark first — whether it is true can only be answered by the rules currently in force in each assessment system.

Three things easily missed in execution

First, consulting and assessment are two different things. Consulting helps you build the process and the evidence; the assessment is carried out by a qualified assessment body under its rules. Industry rules require the two to stay independent, and that boundary applies in the CMMI, ITSS and DCMM directions just the same — do not expect one party to cover everything.

Second, the certificate scope has to match the bidding scope. If the business scope declared at assessment is written too narrow, it will not cover the project content when you bid; written too wide, the evidence will not hold it up. Declare the scope around the business you genuinely run now and will definitely run in the coming year, rather than expanding it to look good.

Third, treat evidence as a daily output, not a project output. Process data, ticket records, data quality reports and security audit logs are worth something not at the moment of assessment, but when you next bid, next face a customer factory audit, or next hit a problem. Whether the system has been built correctly shows here.

Action checklist: five steps to fix this year's list

Have the system owner sit down once with development, operations, data and sales, and tick each line:

• ☐ Collect the tenders. Pull out the tender documents, customer admission forms and framework agreements you already know about for the coming period, and mark on each one which direction and which certificate it asks for, and whether it states a grade, scope and validity period.
• ☐ Label the direction. Group the requirements into three classes: development process, IT service, data (management and security). Anything that will not fit goes on a separate list to ask the customer or the tender agent.
• ☐ Inventory existing certificates and foundations. Which ones you hold, which are expiring, which do not cover the scope; and whether the corresponding processes, workflows and data ledgers actually run, or exist only on paper.
• ☐ Set priorities. Sort by "blocking an order goes first, bonus points only goes later", and state clearly which one is done this year, which next year, and which is not started.
• ☐ Name the people and the interfaces. One owner per direction, with clarity on who produces process data, who produces service records and who produces the data ledger; and who maintains the shared base centrally.

If "collect the tenders" and "label the direction" are not done properly, everything after them is guesswork. With those two solid, selection becomes a mechanical action — do what the document asks for.

Back to the opening line: these five certificates are not five options that can stand in for one another, but five tickets across three directions. Recognise the direction first, then the ticket; read the tender first, then the budget. Reverse that order and the money gets spent while the bid still fails.

▍Not sure which direction, or which certificate? Send us your main business, your main customer types and the requirements in the tenders you hold, and we will work through the three directions line by line and give you a selection view of which to do this year and which next year.

CertFastLine | Export Certification & Testing & Management Systems Consulting This article is a compliance reference for general information, not legal advice; grade structures, assessment scope and applicable scenarios are subject to the rules currently in force in each system and to the tender document itself

Related reading: how to prepare for a CMMI level · how to prepare for ITSS certification · how to prepare for DCMM certification · ISO 20000 IT service management system · ISO 27001 information security management system · DCMM knowledge base · ITSS knowledge base · all management system certifications · quick lookup · contact us