After Picking a CCRC Category: How Should the Evidence Be Prepared?

Why is it harder "after the choice"? Because choosing a category answers "which category should I apply for", while preparing evidence answers a different question: within this one category, which steps will the reviewer trace back through, and can the documents I hold carry that trace all the way to the end? For the same set of projects, integration asks "how do you do security design and hardening", operations asks "how do you prove the service was continuous", and risk assessment asks "can your assessment method be reproduced". The projects do not change; what you are asked to prove does — that is what this article addresses.

One more distinction first, so that two document sets do not contradict each other: CCRC assesses service capability qualification and looks at projects you have delivered; ISO 27001 assesses an organization-level information security management system and looks at whether that system is built and running. The two sets of documents can support each other but cannot stand in for each other (see ISO 27001 certification).

1. The four anchor points of an evidence chain: contract, delivery, people, tools

Whichever category you apply for, the documents that support a project rest on four anchor points. Looked at one by one, each can seem presentable; put them together and they fall apart.

To judge whether the chain is closed, use a one-sentence self-check: pick any project at random — using only this document set, 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 by adding stories.

Evidence shared across categories: organize once, cite many times

A few kinds of material are used by every category. They are worth organizing into one shared base, so that each application does not mean digging through everything again:

• Entity materials: business licence, proof of premises, organisation chart and departmental responsibilities, financial and credit materials. Keep this set maintained and updated over time, and synchronise it whenever the entity changes.
• System documents: policies, processes, work instructions, record form templates. These prove that the capability is repeatable, and they are the part reviewers leaf through frequently during on-site verification.
• People materials: personnel register, employment relationship and social insurance records, education and training records, project history. Build one file per person and add to it as projects come in.
• Tool materials: tool register (name, version, source, purpose, owner) plus usage records (exported results, screenshots, reports).

Shared does not mean carried over as-is. Three ground rules:

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 materials. One number that differs costs time to explain.
2. The same process document must point to this category's activity nodes. The service level management process for operations, the change and rollback process for integration, the risk scoring 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.

2. Information system security integration: link "equipment + implementation" into one construction chain

Integration assesses security construction capability, landing on four steps: defining security requirements, security design, construction and implementation, and security hardening. All four must leave traces in the same project; miss one and the chain breaks at that point.

In practice, two judgements come first:

• Do not force a pure supply project into integration. A project with only an equipment list and an invoice, and no design, implementation or hardening steps, will be empty after two questions during verification. That business is a better fit for operations or another direction, or you wait until you have implementation-type projects.
• The "security content" of an integration project must be pointable. If the contract says "system integration", explain its security design, security configuration, hardening and security testing parts separately: which page of the solution, which line of the list, which record corresponds to which step.

People and tools in this type of project map to the design, implementation and hardening roles, and to configuration checking, baseline management and testing tools. Roles must match the names in the implementation records — the people who appear in the project are the people of that project.

3. Information system security operations: the evidence must prove "continuity"

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.

A complete operations evidence chain usually contains: service catalogue and service level agreement → duty and inspection plan → daily inspection and monitoring records → alert and ticket handling → change management → vulnerability notice and remediation loop → periodic service reports → annual review or renewal. Verification looks precisely at whether this line is continuous: can the service period be reconciled from the contract and the number of reporting periods, and are there long gaps in between.

• Closure matters more than volume. Ten inspection sheets are worth less than one complete record of "problem found — escalated — handled — reviewed — closed". The value of operations shows in the handling process, not in the number of forms.
• Reports must form a series. Monthly or quarterly service reports directly prove service continuity, and each report needs the incidents of that period, the handling results and any open issues.
• People must map to shifts. On-site or remote, how many people, which roles, when on duty — these must match the duty roster and the ticket handlers.
• Tools need exports. Monitoring platforms, vulnerability scanning, log and bastion host tools: attach redacted exports or interface records, stating which customer and which period they were used for.

Level 3 operations is the direction many companies start with; for the specific conditions and material list, work through CCRC Level 3 security operations qualification item by item.

4. Information security risk assessment: the method must be reproducible

Assessment looks at how reproducible the methodology is. One company doing ten projects should have a stable method; during verification, comparing two projects immediately shows whether the method has taken shape.

The evidence skeleton of an assessment project: 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 level above that, you also need what fixes the method in place: assessment work instructions, valuation standards, report templates, quality control and review records.

• Conclusions need a process behind them. A conclusion-only report cannot explain how the risk value was calculated, and that item will struggle to stand. Asset lists, interview records, tool exports and analysis sheets are all part of the process.
• Templates must be consistent, not one per project. A stable method is capability; a different style for every project looks like reports from ten different companies.
• Remediation recommendations must be actionable. The recommendations should correspond one-to-one with the risks found and read as written for this system, not as a stack of generic clauses.
• Personnel competence must map to roles. Who assesses, who reviews, who approves the report — mapped to the role competence for this category.

Another feature of this direction: customers often also need MLPS-related services. Draw a clear boundary between the two kinds of business — which assessment work your company performed, and which results are cited from an external body. Do not mix them in one document set.

5. Emergency handling and disaster backup and recovery: one looks at response, the other at switchover

These two directions are often written up together, but their evidence is entirely different. Preparing them separately saves effort.

Emergency handling looks at the response process. The core evidence is: emergency plan (organisation, contacts, incident grading, handling procedure) → drill plan and drill records → records of real incident handling → handling reports and post-incident review with remediation. Real incidents and drills must be listed separately, not merged into a single line — drill records prove "we prepared", incident records prove "we handled", and neither can stand in for the other.

Disaster backup and recovery looks at objectives and verification. The core evidence is: a statement deriving the recovery objectives (RTO/RPO) from business requirements → disaster recovery solution design → resource and configuration list → switchover or drill records → drill report and issue remediation. Some materials assess disaster recovery separately according to emphasis on resource services versus technical services: the former looks at resource assurance and operations capability, the latter at solution design and drill organisation, so the emphasis of the material differs. The category divisions are subject to the rules currently in force.

One trap worth avoiding: writing emergency handling as if it were operations. Daily inspection and monitoring alerts belong to the operations service process; incident grading, emergency command, recovery and review are the content of emergency handling. When applying for both directions at once, the same record can be cited from different angles, but each direction's steps must be stated clearly.

6. Software security development: put security into the development process

This direction assesses security controls in the development process, not how secure the product's features are. So the weight of the evidence sits on process nodes, not on the finished product.

The usable process nodes are roughly: security requirements (security requirements raised in the requirements phase) → threat analysis and security design → secure coding standards → code audit and white-box testing → open source and third-party component management → security testing (including penetration testing) → pre-release security check → vulnerability remediation loop → release and rollback. Each node corresponds to records from the development process: review records, defect and fix records, test reports, version records.

• Define the business form first. "Own product" and "development services for customers" weigh their evidence differently: the former looks at process execution within the product line, the latter at process execution in project delivery. Pure resale, or pure implementation and deployment business, does not fit this direction.
• Tool reports need project attribution. Code audit and component analysis reports must point to a specific project and version; otherwise it only means "a tool was purchased".
• The remediation loop is key evidence. How many issues were found matters little; what matters is how they were fixed after being found, who verified, and when they were closed.
• Process documents must match project records. If the policy says "security testing before every release", you must be able to produce test records for the corresponding version. Writing something you cannot do is more trouble than not writing it.

7. Network security audit: the process must be traceable for the conclusion to be credible

Audit looks at 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.

Evidence skeleton: 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. Working papers are the key material for this direction — they determine whether the conclusion was "found" or "written".

• Sampling rules must be stated. Why these items were sampled, how many, what scope was covered — writing that down is what makes it a method.
• Findings need evidence pointers. Each finding should indicate which record, which configuration, which point in time, and trace back to the working paper.
• Remediation needs review. Listing issues without tracking remediation leaves half of the audit loop missing.
• State the business boundary. If a company also undertakes construction-type business, explain in the materials how the two kinds of business are kept apart; that is safer than glossing over it.

8. Self-check before you start: six common return reasons and an action list

Returns are usually not because the company lacks capability, but because the documents do not reconcile internally. The six situations below are each worth going through before submission.

One further item is not a "return reason" but must be said separately: writing in projects that are not your company's, or describing a small part you did as the whole engagement. The consequence of this kind of problem cannot be fixed by adding materials. Verification will ask the client, will look at seals and signatures, and will check the timeline; one mismatch anywhere means the credibility of the whole batch has to be rebuilt. Better to submit one project fewer than to let one project damage the entire application.

Action list: ten steps after the category is chosen

• ⬜Write the core step of this category in one sentence (for operations, "continuous service"; for integration, "design — implement — harden"), and align every later document to that sentence
• ⬜List the candidate projects and keep only those your company genuinely undertook and for which complete delivery records can be produced
• ⬜Check, project by project, whether the contracting entity, the executing entity and the personnel's employment relationship are the same entity
• ⬜Draw a step table from requirement to acceptance for each project, marking which evidence exists and which steps are empty
• ⬜Classify the empty steps by "can the original record be recovered": recover and file what you can; for what you cannot, write an explanation or switch projects
• ⬜Build a project master data table (name, amount, start and end dates, participants, deliverables) as the reference for consistency throughout
• ⬜Organize personnel files: role, competence evidence, project role — one file per person
• ⬜Organize the tool register and usage records so that every tool points to a specific project
• ⬜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 materials alone, to see whether the story can be finished

Back to the opening sentence: after the category is chosen, the real work is re-organizing existing projects in the language of that category. Organized well, the projects that look scattered in your hands join into one line; organized badly, even a large pile of contracts is just a pile. Where that line runs depends on your understanding of "what the review will ask" — and that is where the effort is really worth putting after choosing a CCRC category.

▍Not sure which block to fill in first after the category is chosen? Leave a comment noting "CCRC evidence checklist" and I will send you a material mapping table organized by category