ISO 20000 + ITSS: Why Tenders Ask for Both

Bottom line first: ISO 20000 proves "you have a system", ITSS proves "what level your capability has reached". That is not a rhetorical difference — it decides that the two certificates occupy two separate cells on the bid scoring sheet. When a tender writes both rows into its qualification conditions or scoring items, doing one cannot substitute for the other — not because auditors are being pedantic, but because the two never evaluate the same thing to begin with. The reverse also has to be said clearly: what cannot be substituted is the conclusion; what can be shared is the data. The two sets of material draw on the same batch of operating records, so running them together means one less consolidation pass and one less training round, and that saving is real; but the professional core stays where it belongs, and that part cannot be saved.

1. What each certificate covers: one governs compliance, one governs grading

Treating these two certificates as "two country versions of the same thing" is where scheduling, budget and tender wording all start to go wrong. They answer two different questions.

Two scenarios make the distinction easier to see:

• Scenario one: A buyer wants to review your operations delivery and opens your documents — the service catalogue exists, but it does not match the service items in the contract; the SLA promises a 4-hour response, but nobody has ever measured achievement; tickets are scattered across three people's WeChat and no one approves changes. These questions ask "do you have a service management system that can run continuously", which is the ISO 20000 question.
• Scenario two: Two suppliers have both passed ISO 20000 — one has an 80-person operations team, complete monitoring and ticketing platforms and monthly metric reviews; the other has 15 people watching by eye, with night alerts relayed by phone. On the system certificate you cannot tell them apart — a certificate only says "conforms", not "how strong". To separate the tiers you need the ITSS capability level.

This is the fundamental reason both sets of standards exist: system certification judges "is there method", capability assessment judges "what tier is the level at". The former is the internationally used language, the latter the language of domestic tendering. Over the years in consulting we have seen too many companies lose out here — not because capability is lacking, but because the persuasiveness of the two certificates got mixed up; write the wrong positioning into a tender and a review expert can see at a glance that it has not been understood.

2. Why tenders often ask for both: one column for qualification, one for scoring

A tender document is essentially the buyer translating "the risks I worry about" into clauses. In IT operations projects the buyer worries about two things, and worries about them separately:

• Will the delivery process be chaotic? Is there a service catalogue, is there an SLA, do incidents and changes have a process backstop, who is accountable when something goes wrong. What this layer fears is "no method", and it maps to system compliance.
• Is the supplier's level sufficient? If a large-scale outage really happens, can your team, tools and accumulated knowledge carry it. What this layer fears is "no capability", and it maps to capability grading.

Two worries do not disappear at the same time because of one certificate, so a tender usually carries two rows: one for management system requirements, one for capability level requirements. There are two common positions — one in the qualification conditions, where missing one item means you do not qualify; one in the scoring table, where each carries a number of points. The two forms mean completely different things to a company: the first is an admission question, the second a competitiveness question.

That also explains a pattern: many companies discover two weeks before the bid deadline that "one more certificate is missing". It is not bad luck, it is late demand identification. The time cost of a certificate sits mainly in operating records, not in submitting material, so a late discovery leaves almost no room to recover.

3. What can be merged: the two material sets draw on the same data

The two certificates evaluate different objects, but once it comes down to evidence the overlap is large. Once IT operations service actually runs, what it produces is one batch of data to begin with:

The one approach that genuinely reduces effort when running them together comes down to one sentence: unify the data source first, then extract the data once against each set of rules. Do not build two ticketing systems, keep two sets of registers, or issue two service reports with inconsistent definitions — that waste is typical and falls apart the moment someone asks on site.

One layer up, the "management actions" on the ISO 20000 side — document control, internal audit, management review, corrective action — are the running cost of the system itself and have nothing to do with professional depth. Doing them once is enough; there is no need to duplicate a set for ITSS. But watch the boundary: the two sides' requirements for the same record are not identical — what can be shared is the data source, what cannot is the consolidation rule. Re-extracting and re-organising the data against each set of rules cannot be skipped. Specific definitions are subject to the requirements of the certification body and the assessment body.

4. What cannot be merged: two cores, each independent

Save in the wrong place and the cost is being unable to produce the corresponding evidence at on-site verification, followed by rework and rescheduling. The following blocks must each be done on their own.

One more thing that is easily misunderstood: do not schedule the two certificates as "one audit, two certificates". The fields differ, the rules differ, and the conclusions are independent. Whether the on-site arrangements of the two sides can be coordinated into the same period needs confirmation with the certification body and the assessment body and is subject to their assessment and arrangement; do not backward-schedule your internal plan on an "all done in one go" basis, or one delay delays the whole line.

A boundary worth noting in passing: consulting and certification/assessment are two independent roles, and this rule applies to both certificates — do not expect "one firm covers everything".

5. Which companies are suited to doing both together

The test is not size but three intersection points: whether revenue comes from "running IT for others", whether the customer mix spans domestic and overseas, and whether operating data already runs inside systems.

Where a joint build fits

• The business itself is operations service. IT operations service providers, IT outsourcing providers, IDC/hosting, system integrators moving into operations, government and enterprise IT suppliers — the revenue structure naturally matches what the two certificates evaluate.
• The customer mix has both ends. One end is government and central-enterprise operations tenders (which often look at ITSS level), the other is system requirements from foreign-related or foreign-invested customers (which often look at ISO 20000). If you serve both, you need both.
• Ticketing and monitoring systems are already running. The data source is mature, the marginal cost of a joint build is low, and evidence for both sides can be exported from the systems.
• There is a dedicated or stable part-time owner. Someone who can commit continuously for several months to build the system and run the data, and keep maintaining records after certification.

Where doing one first is advised

• Only one is blocking the current order. An extra certificate means extra fees and an extra set of maintenance actions. The one with no customer demand behind it is a net expense.
• Service still depends on people watching by eye. No service catalogue, no SLA register, repair requests relayed by WeChat — in that state the level evidence for ITSS cannot be produced, and ISO 20000 can only be written as paper documents.
• The organisation is relocating, restructuring or switching a core system. Once the record chain breaks, both sides run into trouble at once and rework cost doubles.
• Nobody internally can maintain it over the long term. A small headcount is not the problem; the absence of an owner is.

6. Scheduling and cycle reference

There is one counter-intuitive thing about scheduling: what can be compressed is writing material; what cannot is running data. A system needs actual operating records of a certain duration before acceptance can even be discussed, and the specific duration and acceptance conditions are subject to the certification rules and the body's requirements; capability level depends even more on traceable ticket and metric trails and cannot be manufactured. So whenever someone tells you "both done in two months", ask one question first: where do the operating records come from.

Below are the ranges we commonly use (empirical values; actual figures are subject to the assessment of the certification body and the assessment body):

Combined, the empirical range is roughly from 4–8 months, and longer where the starting point is lower. The variables are not "how fast you want it" but the existing management foundation, the number of teams and sites, tooling maturity and internal response speed.

There is no absolute right or wrong on sequence; look at the revenue structure:

• Mainly domestic tenders — get the service processes and ticket data running first, since the foundation of capability level lies in operation; when the system documents are filled in later they can reuse a large part of the same records.
• Mainly foreign-related or foreign-invested customers — establish the system under ISO 20000 first, then add ITSS for domestic tenders.

The intersection of the two routes is actually the same action: let the service run according to rules and leave traces. That is also why "start moving" is worth more than "decide which one comes first".

7. Cost structure and the logic of saving

Money is spent in three places; only by separating them can you see where the "saving" is:

The saving logic in one sentence: what is saved is "consolidating the same batch of data twice" and "training the same people twice", not any part of the professional content on either side. So when discussing cost, do not ask "can we get a discount for doing both", ask "which work is done once and which must be done twice". The first is a price question, the second a scope question — once the scope is clear, the price follows.

The other side has to be counted as well: the cost of the extra certificate — certification/assessment is charged per certificate, maintenance follows each set of rules, and daily records run per set. So the decision question is not "how much can be saved" but "can the second certificate bring an equivalent order or admission qualification". If yes, run them together; if not, do the one blocking you. Specific amounts need a separate assessment based on organisation size and scope, subject to the body's quotation.

8. Common pitfalls

• Calling ITSS "the domestic ISO 20000". That statement does not stand up professionally: one is management system certification, the other capability assessment, and even the objects evaluated do not fully overlap. Write it that way in a tender and the review question exposes it.
• Using one to cover the other. The customer asks for ISO 20000 and you offer an ITSS level, or the reverse. Provide whichever is required; do not entertain the idea of substitution from the start.
• One set of material with two headers. The two sets of rules extract data differently, and copy-paste material does not survive questioning on site. The data source can be shared; the consolidation rules have to be redone.
• Documents only, no operation. Documents can be written in two weeks; a ticket curve cannot. Assessment and audit look at the real trail inside the systems.
• Blindly pushing for a high level. The higher the level, the more concrete the requirements on operating data, process closure and quantified metrics, and a jump-level application usually stalls at the evidence stage. Do a gap analysis first and move up tier by tier.
• Treating the maintenance requirements as the same. ISO 20000 usually has a 3-year validity plus an annual surveillance audit; the validity and maintenance requirements of an ITSS certificate are subject to the rules in force. Maintain two calendars separately; do not manage two certificates with one table.
• Scheduling on "one audit, two certificates". Two sets of rules, two conclusions; whether arrangements can be coordinated is subject to the bodies. Leave margin in the internal plan for "separate arrangements".
• Stopping once the certificate arrives. If records are not accumulated daily and material is rushed together before maintenance or surveillance, the pain repeats every year.

Action checklist: five steps to decide whether to do both together

We suggest the system owner sit down once with business, operations and sales and tick each line:

• ☐ Go through the tenders. Pull out the tender documents published and in progress over the last 12 months, copy the "qualification conditions" and "scoring items" into two columns, and see whether they name ISO 20000, an ITSS level, or both.
• ☐ Inventory the data sources. Is there a service catalogue, an SLA register, a ticketing system, a monitoring platform? How far back can records be exported? Are the statistical definitions consistent over time?
• ☐ Inventory the people. Who is the system owner? Who runs the service desk? Who maintains the records after certification? How many hours a week can they commit?
• ☐ Set the sequence and the tier. Decide which comes first based on customer mix; set the ITSS target level at the tier the existing evidence can support, not at the tier you wish for.
• ☐ Ask the bodies + backward-schedule. Confirm the accepted scope, how headcount and sites are counted, and whether the two sides' arrangements can be coordinated; then count back from the target bid date and lock down the time needed for operating records.

If "go through the tenders" and "inventory the data sources" cannot be ticked, that usually means now is not the time to do both at once; if both are clear and only staffing is tight, you can proceed, but a schedule 1–2 months wider is safer.

The relationship between the two certificates is, in the end, like a person's degree and professional title: the degree shows you received systematic training, the title shows what tier you have reached professionally. Recruitment looks at both because they do not answer the same question. When a tender asks for both, doing one cannot substitute for the other; but if the same batch of work is done properly, both will hold up.

▍Want to know which one you should do first, and which tier to target for ITSS? Send us your headcount, main business, customer mix and target bid date, and we will produce a dual-certificate path and scheduling reference.

CertFastLine | Export Certification & Testing & Management Systems Consulting This article is a compliance reference for general information, not legal advice; cycles, headcount and costs are ranges only, and specifics are subject to the assessment of the certification body and the assessment body

Related reading: ISO 20000 IT service management system · ITSS information technology service standards guide · how to prepare for ITSS certification · ISO 27001 + 20000 dual system: where a joint build saves · all management system certifications · contact us