CCRC's Eight Categories, One by One: What Each One Reviews and What Evidence It Wants

The eight categories at a glance

Start with the whole picture. The way to use this table is not to "pick a row", but to compare it against the contracts and delivery records you hold, and see which row's evidence focus overlaps with the business you actually run.

1. Information System Security Integration: security implemented into the project, not equipment shipped

What is reviewed

Integration reviews security construction capability, and it lands on four fixed steps: defining security requirements, security design, construction and implementation, and security hardening. All four steps have to leave traces in the same project; miss one and the chain breaks at that step. The test is blunt: can you point to a page of the solution, a line of the list, one specific record, and say at which step "security" was built in — if you cannot point to it, the project has not reached this category yet.

Who it fits

System integrators, security equipment vendors, and companies that design and implement security solutions. Where the contract contains security design, security configuration, hardening or security testing, the project is within scope for organizing; where the team splits design, implementation and hardening across three roles, the fit is closer. Pure supply does not belong in this category: a project with only an equipment list and an invoice, with no design, implementation or hardening, is empty after two questions during verification — wait until you have implementation-type projects before applying.

How to organize the evidence

• Contract: the contracting entity must be the applicant entity; the service scope clauses have to show the design, implementation and hardening steps. Where the contract says only "system integration" or "technical services", explain its security part separately and clearly.
• Delivery records: place them under the four steps — requirement survey records and gap statement, security solution and review records, implementation plan with installation, commissioning and cutover and rollback records, hardening baseline and configuration checks, test and remediation closure, acceptance report. Each step needs at least one document that can be read on its own.
• People: the people in the project role table must be findable, with the same name and the same role, in the implementation records and the acceptance signatures; design and hardening are often different people — do not write one person as covering everything.
• Tools: configuration checking, baseline management and testing tools, with redacted exports, stating which project and which stage they were used in.

Common return reasons

• Pure supply forced into integration. The project has no design, implementation or hardening — only a purchase list and goods receipt — so the project does not correspond to the category.
• The solution is a vendor template. Topology, equipment selection and configuration baseline have no correspondence to this project's actual state, so it is not visible that the design was made for this customer.
• A list without a process. The equipment list is complete, but installation and commissioning, cutover and change records are missing, so how risk was controlled during implementation cannot be explained.
• Hardening records are a generic template. With no check results for this project and no remediation closure, the hardening step counts as not done.

2. Security Operations: proving "still doing it", not "did it once"

What is reviewed

The core of operations is not "having done it" but still doing it. So its evidence takes a different shape from other categories: not a deliverable at a single point in time, but a service record along a timeline. Verification looks at whether that line is continuous — can the service period be reconciled from the contract and the number of reporting periods, are there long blank stretches in between, and did issues run all the way from discovery to closure.

Who it fits

IT operations and on-site service providers, and companies that maintain security equipment and security platforms for customers. Annual maintenance, on-site duty and platform managed service — periodic contracts — fit this category naturally. Many IT service companies start here because operations contracts are relatively common and service records form a series easily; but "common" does not mean "easy" — where continuity cannot be shown, the file still comes back.

How to organize the evidence

• Contract: a service catalogue and service level terms, the service term, and traces of renewal or annual review. Where there is a framework agreement with no specific orders under it, complete the orders first and then talk about applying.
• Delivery records: duty and inspection plan, daily inspection and monitoring records, alert and ticket handling, change management, vulnerability notices and remediation closure, periodic service reports. Reports must form a series, and each one carries the incidents of that period, the handling results and any open issues.
• People: on-site or remote, how many people, which roles, when on duty — these must match the duty roster and the ticket handlers. Staff on the roster whose social insurance sits with another entity is a frequent sticking point in this category.
• Tools: monitoring platforms, vulnerability scanning, log and bastion host tools, with exported results or interface records attached, stating the customer and the time period.

Common return reasons

• Ten inspection sheets, not one closed loop. Closure matters more than volume: one complete record running "found — escalated — handled — reviewed — closed" is worth more than a pile of ticked forms.
• Reports do not form a series. The contract covers a year of service but the reports cover two months, and the blank in between cannot be explained as continuous service.
• A one-off delivery reported as operations. The project has a single go-live or a single remediation round and no periodic service process, so in form it is not this category.
• A long tool list with no usage record at all. Tool names and versions are listed, but which customer and which period they served cannot be stated.

For the specific conditions and material list of this category, work through CCRC Level 3 security operations qualification item by item.

3. Security Risk Assessment: can another person reproduce the method

What is reviewed

Assessment reviews how reproducible the methodology is. One company doing ten projects should apply a stable method; during verification, putting two projects side by side shows at once whether the method has taken shape. One layer further in, it is the process behind the conclusion: how the risk value was calculated, what the grading rules are, who reviewed it. A conclusion-only report that cannot explain the calculation will not hold up.

Who it fits

Bodies and companies doing MLPS testing, classification and filing, and security assessment, and consulting teams with a stable assessment method and a review mechanism. The test is not "we can do assessment too" but whether the assessment projects you have already delivered share one report structure — if every project is written differently and the set looks like reports from ten separate bodies, this category does not hold yet.

How to organize the evidence

• Contract: state the assessment object, scope, deliverables and the form of the results. A contract with a vague scope makes it hard to prove afterwards what exactly was assessed.
• Delivery records: assessment basis and scope, asset identification and valuation, threat and vulnerability analysis, risk calculation and grading rules, assessment conclusions, remediation recommendations, report delivery and customer confirmation. One layer above that, you also need what fixes the method in place: work instructions, valuation standards, report templates, quality control and review records.
• People: who assesses, who reviews, who approves the report, mapped to role competence. The review step is often left out, yet it is precisely the evidence that the method is stable.
• Tools: exports from testing and analysis tools, stating which project they were used in and which part of the conclusion they support.

Common return reasons

• Conclusions without a process. The asset list, interview records and analysis sheets are all empty, so the risk value cannot be recalculated.
• A different template for every project. An unstable method is the same as no method.
• Remediation advice is a stack of generic clauses. The advice does not correspond to the risks found, so it does not read as written for this system.
• The MLPS boundary is not drawn. Which assessment work your company performed and which results are cited from an external body are mixed in one document set, so neither responsibility nor capability can be stated clearly.

4. Security Incident Response: drills prove preparation, incident records prove handling

What is reviewed

Incident response reviews response capability, from preparation to handling to review — one complete capability chain: is there a plan, has it been exercised, how is a real incident handled, is there a review and remediation afterwards. One line is easily blurred here: drill records prove "we prepared", real incident records prove "we handled", and neither can stand in for the other, so they are listed separately and never merged into one line.

Who it fits

Providers and teams doing red team exercises, emergency response and security incident handling. Where there is real incident handling experience, the material stands on firmer ground; companies that mainly organise drills can also organize this category, but the weight goes on the completeness of the plan, the organisation of the drill, and the review and remediation — do not use drill records to fill the place of incident records. Daily inspection and monitoring alerts belong to the operations service process and should not be pushed into this category.

How to organize the evidence

• Contract: emergency services, drill organisation and incident handling are three types of contract and should be distinguishable; the service content has to show the "response" step, rather than a general security service.
• Delivery records: the plan needs organisation, contacts, incident grading and handling process; drills need a plan and records; real incidents need handling records and a handling report; both need review and remediation. The value of an incident record lies in the timeline — discovery, escalation, handling, recovery, review, all five points written clearly.
• People: the command, handling and review roles must match the organisation chart in the plan and the handlers named in the incident records.
• Tools: forensic, analysis and monitoring tools, with records of their use in a specific incident or drill — not an equipment list.

Common return reasons

• Incident response written as operations. The material is all inspection and alert handling, with no incident grading, emergency command, recovery or review in sight.
• Drills and incidents merged into one line. The same record serves as both a drill and an incident, and the probative value of each is weakened.
• Every drill record went smoothly. No issues found and no issues remediated, so the authenticity of the process does not survive questioning.
• Incident records carry only conclusions. "Recovered" is written, but there is no timeline, no handling steps and no review.

5. Secure Software Development: the security nodes in the development process, not the features of the finished product

What is reviewed

This direction assesses security controls in the development process, not how secure the product's features are. The weight of the evidence therefore sits on process nodes, not on the finished product: are security requirements raised in the requirements phase, is threat analysis done in design, is there a coding standard, are code audit and testing performed, how are findings fixed, who verifies closure. If the policy says "security testing before every release", you must be able to produce test records for the corresponding version — writing what you cannot do is more trouble than not writing it.

Who it fits

Companies with their own software products, and teams that develop software for customers. The two businesses weigh their evidence differently: the first looks at process execution within the product line, the second at process execution in project delivery. Pure resale, or pure implementation and deployment, does not fit this direction — with no development process there is no evidence for this category.

How to organize the evidence

• Contract: software development or product delivery contracts whose deliverables show the system and the version; where the software is developed for a customer, the contract must map to a specific project.
• Delivery records: security requirements, threat analysis and security design, secure coding standard, code audit and white-box testing, open source and third-party component management, security testing, pre-release security check, vulnerability remediation closure, release and rollback. Each node keeps review records, defect and fix records, test reports and version records.
• People: development, security testing or code audit, and release approval are kept as separate roles; where one person holds several, the records must show signatures at the different steps.
• Tools: code audit and component analysis reports must point to a specific project and version, otherwise they only prove that a tool was purchased.

Common return reasons

• Product feature descriptions used in place of process records. A long account of security features, with not one record of a security node in development.
• Tool reports with no project attribution. The report is a generic scan result; which system and which version were scanned is unknown.
• Only a fix list, no verified closure. How many issues were found matters little; what matters is who fixed them, who verified, and when they were closed.
• Process documents and project records living in two worlds. The forms the policy requires never appear in an actual project.

6. Disaster Backup & Recovery (Resource Service): resources exist, can switch, and are verified

What is reviewed

The resource service direction reviews resource assurance and operations capability: do you hold disaster recovery resources that really exist and can be used — data centre, equipment, cloud resources — are they running continuously, can you switch over when needed, and can service be sustained after the switch. It lands on two words, "resource" and "verification" — a resource list with no switchover verification leaves this category empty.

Who it fits

IDCs, cloud providers, and companies that build their own disaster recovery centres and offer resources externally. Where a deliverable resource list exists and a team is responsible for resource operations and switchover, the fit is close. Conversely, a company that does not hold the resources and only does solution design and drill organisation should look at technical service and not force its material into this direction.

How to organize the evidence

• Contract: resource lease or disaster recovery centre service contracts, stating resource type, capacity, service term and availability arrangements; a framework agreement needs specific orders.
• Delivery records: resource and configuration list, a statement deriving the recovery objectives from business requirements, switchover or drill records, drill reports and issue remediation, daily operations records. Recovery objectives are not numbers picked out of the air — there must be a derivation.
• People: the resource operations, switchover operation and drill organisation roles must match the duty arrangements and the operators named in the drill records.
• Tools: platforms or tools for monitoring, backup and switchover drills, with operating records and records of the operations performed during the drill.

Common return reasons

• Only data centre photos and a resource list. Without switchover or drill verification, "it can switch when needed" cannot be shown.
• Recovery objectives picked out of the air. No statement deriving them from business requirements, and the objective values do not match the resource investment.
• Resource service written as solution design. The weight shifts to the solution text while resource and operations records are missing, so the direction is wrong.
• The drill report says only "successful". No process, no elapsed time, no issues and no remediation — verification counts as not done.

7. Disaster Backup & Recovery (Technical Service): the solution lands, the drill can be organised

What is reviewed

The technical service direction reviews solution design and drill organisation capability: how the recovery objective is derived from business impact, how the solution lands on resources and concrete steps, how switchover order and rollback are designed, how the drill is organised and how the issues found are closed. The difference from resource service is clear — this category does not require the resources to be yours, but it does require the method and the organisation to be yours.

Who it fits

Disaster recovery solution providers, system integrators, and teams doing disaster recovery construction and consulting. The customer is buying your design and your organisational capability; the resources may sit in the customer's data centre or a third party's, and that business shape corresponds exactly to technical service. The test is: what you deliver is a solution, steps, drill organisation and reports — not racks and bandwidth.

How to organize the evidence

• Contract: disaster recovery solution design, disaster recovery construction and drill organisation contracts, whose service content shows the design or the drill step.
• Delivery records: business impact and recovery objective statement, solution design including switchover order and rollback, resource and configuration recommendations, drill plan and records, drill report and remediation. The solution must carry business judgement for this customer, not a generic template.
• People: the solution design, drill command and switchover operation roles; the division of labour on the drill day must be visible in the records.
• Tools: design and drill support tools, switchover scripts and operating records, stating which customer and which drill they served.

Common return reasons

• The solution is a generic template. With no business impact analysis, the recovery objectives do not read as derived from the customer's business.
• A solution without a drill. Design capability exists only as text, with no verification ever organised, so it cannot land.
• The drill has no rollback steps. Only how to switch over is written, not what happens if it has to be reversed, so the risk control link is missing.
• The two disaster recovery directions borrow each other's material. A resource list presented as a technical service output, or solution text presented as proof for resource service, and neither side matches.

8. Network Security Audit: the working papers decide whether the conclusion was found or written

What is reviewed

Audit reviews how standardised and traceable the checking and evaluation are. It differs from risk assessment in where it lands: assessment points to risk and remediation priority, audit points to conformity and inspection conclusions. So this category does not look at how polished the conclusion is, but at whether every conclusion traces back through the working papers to a specific record, configuration and point in time. The working papers are the key material for this direction — they decide whether the conclusion was "found" or "written".

Who it fits

Security audit and consulting providers, and companies doing compliance checks and conformity evaluation. Where a company also undertakes construction-type business, the material must explain how the two kinds of business are kept apart and how audit independence is arranged — glossing over this invites more questions than stating it plainly.

How to organize the evidence

• Contract: audit scope, object and basis stated clearly; a contract with an over-broad scope makes "what was checked" hard to define later.
• Delivery records: audit basis and scope, checklist of inspection items or control points, evidence-gathering methods (interviews, configuration checks, log and record inspection), sampling rules and sample description, findings and grading, audit report, remediation tracking and review. The working papers correspond to the report item by item.
• People: audit, review and report approval kept separate; the review records are direct evidence of standardisation.
• Tools: exports from configuration checking and log analysis tools that point to a specific inspection item and sample.

Common return reasons

• No working papers. The findings in the report trace back to no record at all, so they read as written from a template.
• Sampling rules cannot be stated. Why these items were sampled, how many, what scope was covered — if that cannot be answered, it is not yet a method.
• Issues listed without remediation tracking. Half of the audit loop is missing, so the evaluation capability has not been shown in full.
• The construction and audit boundary is unclear. The same people both build and audit, with no distinction in the material, and both independence and objectivity will be questioned.

9. Evidence shared across categories: organize once, cite many times

The eight categories review different things, but a block of material is used by all of them. Organizing that block once into a shared base saves far more effort than digging everything out again for each application, and it is easier to keep consistent.

Shared does not mean carried over as-is. There are three rules, and breaking any one of them shows up during the cross-check:

1. One version per data point. Project name, contract value, start and end dates, number of participants must be identical in the application form, the project description and the acceptance material. One number that differs costs time to explain.
2. The same process document must point to this category's activity nodes. Service level management for operations, change and rollback for integration, risk valuation rules for assessment — they point to different clauses. Writing only "we have this policy" means nothing.
3. When applying for different categories separately, do not carry category A's narrative straight into B. The same project can be used under both categories, but the deliverables and steps cited must be swapped for the part B cares about.

There is a simple self-check for whether this base is sufficient: pick any project at random — using only this material, can you tell the whole story of who, at what time, with what means, did what for the customer, and how the customer confirmed it, without adding anything verbally? The link you cannot finish is the link to fill in — by adding records and explanations, not stories.

10. Levels and the upgrade path: moving up inside one category

Every category is graded Level 3, Level 2 and Level 1. Level 3 is the entry point; Level 1 asks more of accumulated capability. Level 3 looks at whether the basic capability in this direction holds; Level 2 looks at the stability of the capability and the coverage of projects; Level 1 looks at how systematised it is, the technical means, and the ability to carry complex projects. The level changes what has to be shown, but it is the same capability at different depths — not a different set of material.

Four judgements about upgrading are worth remembering:

• Level depends on capability and cases, not years in business. A company that has traded for ten years on thin projects does not reach Level 2 just by being old.
• Level 3 first, then upwards. After Level 3 is granted, run it for a while until projects, people and system documents all flow smoothly, then apply for Level 2 — the material is then unhurried. Going straight for a high level means any mismatch in people, projects or system documents sends the file back.
• Upgrading is not changing category. Categories differ by direction of capability, not by difficulty. If integration does not flow, switching to operations will not solve the evidence problem.
• When running several categories in parallel, separate the angle of citation. Applying for integration and operations at the same time is common; the same projects can be used, but each category should point only to the steps it cares about. A certificate is valid for 3 years and must be renewed as required; projects added in the meantime should keep being filed — do not go looking for them just before expiry.

11. Action list: from category to material, in this order

After reading all eight categories, the work comes down to a single line. Do not reverse the order — fix the category first, then take stock of the projects, then fill the gaps, and only then talk about documents.

• ⬜Write the core step of your intended category in one sentence (integration is "design — implement — harden", operations is "continuous service", assessment is "method can be reproduced", incident response is "response and review"), and align every later document to that sentence
• ⬜List the candidate projects and keep only those genuinely undertaken by your own company for which complete delivery records can be produced
• ⬜Check item by item whether the contracting entity, the executing entity and the personnel's employment relationship are the same entity, and deal with anything cross-entity first
• ⬜Draw a step table from requirement to acceptance for each project, marking which evidence exists and which steps are empty
• ⬜Sort the empty steps by "can the original record be recovered": file what can be recovered; for what cannot, write an explanation or switch projects
• ⬜Build a project master data table (name, amount, start and end dates, participants, deliverables) as the reference throughout
• ⬜Organize personnel files: role, competence evidence, project role — one file per person, with social insurance and employment relationship checked separately
• ⬜Organize the tool register and usage records so that every tool points to a specific project and period
• ⬜Make the clauses of the system documents correspond one-to-one with this category's steps, and unify the forms with the forms actually used on projects
• ⬜Before submitting, run a cross-check: pick two projects and retell the whole process from the material alone, to see whether the story can be finished

By this point the eight categories come down to one sentence said eight ways: what you have genuinely delivered in this direction is what the material must be able to describe so that someone else can check it. Category right, and the material is organizing work; category wrong, and the material has to be redone. The difference between the two often lies in whether you thought through "what is reviewed" in each category before picking anything up.

▍Not sure whether you have enough evidence for your category? Leave a comment noting "CCRC per-category checklist" and I will send you a material mapping table filed by the eight categories