ITSS Levels Explained: Level 1 to Level 4

Bottom line first: the gap between ITSS Level 1 and Level 4 has never been about how thick the documents are. It comes down to three things — service scale, tooling and continual improvement — and whether you can produce evidence for them. Documents can be written in a rush; service scale is built by running a business; tool data comes out of systems that actually run; an improvement loop is accumulated over time. So at each step up, what really becomes harder is not "a few extra requirements" but "do you have any history behind this kind of evidence".

Compress the four levels into one line: from Level 4 to Level 3, the test is whether you "have processes"; from Level 3 to Level 2, whether you "have a system"; from Level 2 to Level 1, whether you "exercise field leadership". Follow those three lines into the requirements at each level and you will find the same business described at different stages of maturity — not four exam papers of increasing difficulty.

First, correct a misunderstanding that turns up time and again: with ITSS, the smaller the number, the higher the level — Level 1 is the higher level and Level 4 is the entry level (the specific grading and how it is determined are subject to the assessment rules in force). More than a few companies have written the target level backwards in a bid document, or treated "Level 4" as the senior grade when they set up an internal project, and only found the direction was wrong when they came to compare against the gap. Another frequent failure is writing documents at a high level while running services at a low one: the service catalogue in the paperwork is broken into a dozen tiers and every SLA metric is in place, yet the system holds only a handful of test tickets — one spot check on site exposes it.

The table below is the skeleton of this article. It gives no specific threshold figures — headcount, number of projects, contract value, assessment scores — because requirements differ by level and shift with the rules of the period; in all cases they are subject to the assessment rules in force. What the table gives is what each level looks like in capability, what evidence people will ask for, and who usually applies.

There is a way to read this table: look at the third column first, then the second. The second column says what the capability looks like, which makes people feel "we are roughly there"; the third column says what people will come and ask for, and that is the gate you either pass or fail. When many companies self-assess, their judgement of their own capability is right and their judgement of "what traces that capability has left" is wrong.

1. Level by level: what differs is not the number of requirements but the density of evidence

Moving up level by level is not "one more layer of documents" but how many layers of evidence you can produce for the same thing. Level 4 can prove "someone did this"; Level 3 can prove "this was done to a process"; Level 2 can prove "this is being done better and better"; Level 1 can prove "this way of working holds up somewhere else". That is the real dividing line between the four levels.

Level 4: catch the service first, and leave records that can be checked

Level 4 is the entry tier, and the core of what it examines is that you really are providing IT O&M services to external clients, and that the service process leaves basic traces. At this stage the tooling does not have to be complete — spreadsheets, email and a lightweight ticketing system all work; but the traces have to be continuous and traceable, not assembled in the week before the assessment.

This tier usually has to answer four questions: when a customer reports a fault, who do they contact? Once they reach that person, what steps are followed? After handling, is there a record? Can that record be matched to a specific customer and a specific time? Answer the four smoothly and the foundation for Level 4 holds; fail one and the problem usually is not "the document does not say" but "the service entry point itself is unclear".

A common self-inflicted wound at Level 4 is buying a system in order to look well governed. The system holds a few test records, the ticket titles say "test" and the handler says "admin" — that kind of evidence does not add credit, it states plainly that the tool is decoration. Lightweight but real always beats complete but idling.

Level 3: run the processes into closed loops

Level 3 is the line between "people are working" and "the organisation is working to processes". The key word at this tier is closed loop: the service catalogue has to match the services customers actually buy, the SLA has to state response and resolution times and be counted on one and the same basis, an incident has to move from intake to closure with defined stages, owners and deadlines, changes need approval, and the monthly service report has to explain how operations ran over that period.

What is genuinely hard at Level 3 is not writing processes but keeping processes and statistical definitions consistent. A common case: the SLA says "four-hour response during business hours", the monthly report counts "average response time around the clock", both numbers are "on target", yet the bases do not match — and the moment an assessor asks "how was this attainment rate calculated", the chain breaks. What Level 3 requires is this: every stage of a ticket, from creation to closure, carries a timestamp, and any report can be traced back to the original tickets.

This tier is also where many government and enterprise O&M tenders set their threshold (subject to the wording of the tender document), so in practice Level 3 often offers a good return on effort: the tools and processes it requires are the ones you already need to take on an annual O&M contract, and the records it requires are the ones you already need to produce a monthly report for the customer. Nothing extra has to be manufactured for the assessment.

Level 2: run the system into data

The dividing line at Level 2 is quantification. Level 3 proves "the processes are running"; Level 2 has to prove "you know how well they are running, and you know before the customer does". This tier usually looks at whether metrics have a baseline (what it was last year), a target (what it should be this year), a trend (up or down over consecutive periods), and an explanation for any anomaly.

Level 2 also requires that scale is manageable. When several projects and several sites run in parallel, are they using the same templates, the same definitions and the same review rhythm? If every project manager writes their own monthly report and defines metrics differently, then even good single-project results do not demonstrate organisation-level capability — and that is exactly what Level 2 examines.

Another dividing point is problem management. Level 3 handles incidents (fix the fault); Level 2 handles problems (find out why it keeps recurring, and whether the fix held). The difference is concrete: the knowledge base at Level 3 holds "operating instructions", the knowledge base at Level 2 holds "post-mortem conclusions". The first teaches people how to do something; the second tells the organisation where it has slipped.

Level 1: run the capability into something replicable and referenceable

Level 1 is the higher level. What it examines is not "you do it a bit better than others" but whether your service capability has come free of dependence on particular people and particular projects: change the city, change the customer, change the team — does the delivery standard hold; has the service been productised (clear service items, delivery standards, a way of measuring), rather than renegotiated for every project.

Level 1 also looks at risk and continuity: when a critical system fails, is there a plan, has it been rehearsed, were the issues found in the rehearsal fixed. And at outward contribution: whether methods have been captured in a form peers can reference, and whether the team takes part in industry exchange, standards practice and talent development. To be clear, these describe what capability at this stage usually looks like; they are not a clause-by-clause application checklist. The specific criteria for Level 1 are subject to the assessment rules in force.

For the large majority of companies, Level 1 is a business outcome, not a project target. It tends to appear in organisations that have operated at scale for years, whose service offering has taken shape and whose management system is stable. Treating it as a one-off application exercise costs far more than it returns.

2. People and roles: the level difference lies in "backup" and the "competence matrix"

On people, the difference between the four levels is not headcount but whether posts are aligned with process roles, whether critical posts have backups, and whether competence can be measured. Headcount thresholds differ by level and follow the rules in force; what follows is about structure.

Level 4 looks at "someone is responsible". The service manager, first-line intake and second-line handling roles can be mapped to named people; holding several roles at this stage is normal, as long as responsibilities are stated and records can be matched to the person.

Level 3 looks at "the roles close the loop". Post titles may differ from the roles named in the processes, but the mapping has to exist: who takes intake, who dispatches, who escalates, who closes, who does the customer follow-up call. This tier usually needs appointment documents, job descriptions and training records. A frequent follow-up question in assessment is: "for the person who handled this ticket, is this among the duties of their post?" If there is no answer, the post structure is decoration.

Level 2 looks at "competence that can be measured". The core is the competence matrix — which skills a post needs, what level each person is at, how gaps are closed, who provides backup. Add shift and handover records: who is on duty over holidays, what was handed over between shifts, who to escalate to at night. These look trivial, but they are the direct evidence that "the service does not stop when a person does".

Level 1 looks at "a pipeline that can be replicated". Critical posts have a defined development path and named successors, cross-region deployment has a mechanism, and staff turnover does not drop the service level for any customer.

3. Tooling: from "having a system" to "having data" to "having automation"

Tooling is one of the areas where a level difference can easily be "bought" and just as easily seen through. There is only one test: is the tool carrying the process, or performing a pantomime of it?

By function it usually covers six categories: service desk and ticketing (intake, dispatch, hand-off, closure), monitoring and alerting (infrastructure, applications, network), configuration management (a CMDB that states which assets exist and how they relate), knowledge base (capture and reuse), automation (bulk operations, scripts, automated inspection), and reporting and measurement (turning data into a management view). The depth of coverage across the four levels differs:

• Level 4: there is an entry point. Tickets can be created, dispatched and closed, monitoring shows alerts, and exports are line-item detail. Even spreadsheets plus email are acceptable, as long as they are genuinely in use.
• Level 3: there are processes. Ticket stages are tied to SLA deadlines, changes go through approval, inspections have a plan and results, and reports come out on a fixed basis. The tool starts governing people, instead of people routing around the tool.
• Level 2: there is data. Ticket, monitoring and CMDB data reconcile with one another — an alert raises a ticket, the ticket links to a configuration item, the configuration item links to a customer and a service level. Metrics can be cut by project, by customer and by time.
• Level 1: there is automation and decision-making. Repetitive actions are replaced by automation, capacity and availability have predictive views, and the data the tools produce feeds directly into management review and resourcing decisions.

On a site check there is a plain verification method: pick a date at random, have the team pull every ticket from that day out of the system, then reconcile them against that day's duty roster, alert log and the customer monthly report. If the three reconcile, the tooling is real; if they do not, at least one of them was assembled afterwards.

One more reminder: building in-house or buying in does not by itself add or subtract credit. An open-source ticketing system run properly beats a commercial platform used only to export screenshots. The assessment cares whether the data is continuous, exportable and consistent with the service actually delivered — not the brand on the software.

4. Knowledge base and continual improvement: the step that is easily underestimated

If you were to pick one link that "looks simple, actually blocks people", this is it. The bar for a knowledge base is very low — create a folder, upload a few documents, anyone can do it; but proving that it has been used, been updated and been trusted has no shortcut.

Level 4 to Level 3 tests "whether it exists". Does the knowledge base hold operating instructions corresponding to the service catalogue, methods for handling common issues, and an emergency contact list. This tier allows few entries, but not a stack of empty folders.

Level 3 to Level 2 tests "whether it is used". The test is direct: in the resolution of tickets, is there any trace of a knowledge entry being cited; do new joiners get up to speed from the knowledge base rather than by asking the old hands; do entries have a reviewer, and are expired entries retired. A knowledge base with only upload dates and no modification dates is essentially a file-sharing drive.

Level 2 to Level 1 tests "whether it feeds back". Knowledge entries come from problem post-mortems; post-mortem conclusions change processes, tools and training; improvement items have an owner, a deadline and a verification result; the effect of the last round of improvement shows up in the next round of metrics. That is the closed loop people talk about — not drawing a PDCA circle, but being able to cite a concrete case: a recurring problem, from being spotted to being eliminated at the root, and what changed along the way.

A practical suggestion here: prepare three to five "improvement stories", and in each one make five things clear — what the problem was, what the root cause was, what changed (process, tool, people), how you verified the change worked, and where the change was captured (knowledge entry, process document, training material). Answer those five completely and the continual improvement item largely stands up; answer them incompletely and no amount of writing about a "continual improvement mechanism" will fill the gap.

5. Project scale and complexity: how to prove "my service scope reaches this level"

Many people read scale as "large contract value, many projects". What the assessment actually looks at is not the money but whether the complexity is under control. Take the same annual framework contract: pure equipment maintenance and integrated O&M covering on-site staffing, application operations, night duty and change implementation are not remotely in the same league.

So the right way to prove scale is to describe the service structurally, rather than to quote a few numbers:

• Service objects — data centres, networks, endpoints, application systems, cloud resources, with their share and criticality
• Service models — on-site, remote, hybrid, with the intake channel and response mechanism for each
• Coverage — geography, number of sites, scale of connected users, criticality tier of the systems
• Service intensity — strictness of SLAs, change frequency, alert volume, duty hours
• Management mechanism — how planning, review and resource allocation are unified when several projects run in parallel

The matching evidence then becomes obvious: contracts and the service catalogue show "what is done", the organisation chart and shift rosters show "who does it", the multi-project views in the tools show "how it is all held at once", and cross-project meeting minutes and common templates show "it is not everyone doing their own thing". Put those together and the scale is verifiable; without them, saying "we serve a lot of customers" means nothing.

There is a pitfall on the other side too: the contract is not substantively O&M. Equipment purchases with a few years of warranty, software development with a stretch of free maintenance, the commissioning period inside a system integration project — all of these are legitimate revenue, but when used to prove O&M service capability they often fail to line up with the "service catalogue + SLA + continuous service records" chain. Filtering contracts on "is this continuous O&M" before you apply is less work than explaining afterwards.

6. Common upgrade paths: move up one step at a time, do not skip

Think of the levels as a building where Level 4 is the ground floor and Level 1 the fourth: the large majority of companies walk up a floor at a time rather than being lifted from the ground to the top. Three paths are common, each with its own fit:

Path one: system first, level second. Build the service catalogue, SLAs, incident and problem processes, service desk and knowledge base to ISO 20000 first, run them for a while, then apply for ITSS using the same operating data. The advantage is that documents and records are produced once and reused on both sides; the cost is concentrated upfront investment and slower visible progress. Companies already running ISO 20000 usually travel this path smoothly.

Path two: take a lower level first, run a full cycle, then upgrade. Suited to teams whose service has just taken shape and whose records are still thin. Use Level 4 or Level 3 to make "working to process" a habit, accumulate tickets, monthly reports and post-mortems into continuous history, then close the gap to the next level in tools and quantification. Upfront investment is small and risk is low, but note this: an upgrade looks at whether the evidence the next level requires already exists continuously, not at how long has passed since you were certified.

Path three: work backwards from the tender date. This is common in practice — see which level the target project's tender document names and when bids open, then work back to the preparation period you need. If time is short, the sensible move is a different lot, a different project, or bidding first for tenders that do not require that level, rather than compressing the record period and forcing it through. What gets missed when scheduling backwards is not the time to write documents but the time records need to grow naturally.

On skipping levels, plainly: whether the rules allow a skip and whether you can skip are two different questions. The first depends on the rules of the period, the second on the evidence chain. The risk of a skipped application concentrates in three places: the records do not span enough time (one or two months of data cannot show a trend), definitions are unstable (each project manager writes their own), and the site interviews do not reconcile (what management describes as the objective and what the front line describes as the process are not the same thing). If any one of those three is probed, the credibility of everything in front of it is discounted with it.

If you are still deciding the order between ITSS and ISO 20000, these two articles are worth reading side by side: the full ITSS certification process: conditions, materials and timeline, and how to combine ISO 20000 and ITSS; for the conceptual distinction see the ITSS knowledge base entry.

7. Common pitfalls: six real rework points

• Documents written to a level, services run as they are. The service catalogue in the paperwork is broken into three levels of menu and every SLA metric is in place, while the tickets in the system cover half the business. The assessor does not need to hunt for a gap; one random draw is enough.
• Mistaking "having a system" for "having tooling capability". A platform was bought but processes still run offline and data is entered retrospectively at month end. Backfilled data has obvious features: creation times clustered in the same hour, closure times neatly uniform.
• Everyone counts on a different basis. SLA attainment, average response time, first-time fix rate — sales, project managers and the author of the monthly report each have their own formula. Level 2 and above are especially sensitive to this.
• Entity and people out of alignment. Contract, social insurance and actual employment sit with three different entities. This kind of issue surfaces at pre-review, and fixing it takes a long time.
• Knowledge base and improvement stuck at "established". There is a folder, a policy and an appraisal, but no citation records, no post-mortem cases and no verification conclusions. This is a frequent source of lost marks on the way from Level 3 to Level 2.
• Records break off after certification. The certificate has a validity period, during which you have to maintain the system and accept surveillance as required, and schedule re-assessment before expiry. Letting up once certified means starting from zero at re-assessment — which is the real reason many companies "did it twice and paid twice".

Action checklist

Go through this in order before you start, and move on only when you can give a concrete answer to each line:

• ⬜ I can say in one sentence which type of O&M service customers paid for over the past one to two years (on-site, remote, data centre hosting, application operations, annual maintenance)
• ⬜ I can produce the contracts in force corresponding to that service, and the contract content is substantively continuous O&M, not procurement or development
• ⬜ The contracting entity, the social insurance entity and the project-executing entity are the same company, and the three tables have been reconciled
• ⬜ I know the target level's requirements on headcount, projects and sites (subject to the assessment rules in force), rather than having heard them from a peer
• ⬜ My ticketing system holds continuous real data, and I can pull any given day's records and reconcile them with the shift roster
• ⬜ The SLA metric definitions and the monthly report's statistical basis are one and the same, and any report can be traced back to the original tickets
• ⬜ I can tell three complete improvement stories: the problem, the root cause, what changed, how it was verified, where it was captured
• ⬜ I know whether I should "build the system first" or "take a lower level and run one round", and I have weighed the time cost of both

If fewer than five of these eight can be ticked, now is not the moment to submit an application — closing the gaps first is much faster than submitting and being sent back. On levels, stability beats ambition: certifying one level lower, thickening the records and then moving up usually saves more time, and more internal effort, than one push for the top that gets returned.

Where things are unclear, you can contact us directly and go through it line by line; you can also start with the management systems overview to see the domestic and international tracks side by side. For the information security counterpart, see CCRC information security service qualification; for self-check tools and checklists, see quick lookup; and to see how peers put an O&M system into practice, see customer cases.

▍Not sure which level to apply for, or want to know which items of evidence are still missing between Level 3 and Level 2? Leave a comment or message me with "ITSS level check" and I will send you a level-by-level gap self-check sheet.

This article is a compliance reference for general information, not legal advice; level settings, threshold requirements, assessment methods and cycle costs are all subject to the current requirements issued by the ITSS branch and the relevant assessment bodies.