Government bids vs financial clients: where CCRC actually differs

Two types of client side by side: one table to see where the paths split

Start with the whole picture. The way to use this table is not to pick a side, but to hold it against your own revenue mix: whichever column is closer to where your money will come from over the next two years is the column where the preparation weight belongs. In reality plenty of companies are hybrids — bidding for government IT work and also running operations for industry clients — and a hybrid has to judge row by row rather than copy a whole column: the categories can be applied for in one go, but the evidence has to be filed in two orders, by project.

1. Choosing the category: integration, operations or risk assessment first

On the question of which category to apply for, the two types of client differ little; the difference is who decides for you. On the government route the tender document decides, on the finance route the service ledger decides. That looks like a question of sequence, but it decides where the money goes first.

Government route: work backwards from the eligibility clauses

The method is plain, yet few companies actually do it: take the tenders you have bid over the past period and the ones you plan to bid, copy out every category named in the eligibility clauses, and build a frequency table. The category named often goes first; one that appeared once goes later. After this step, the category you apply for is not "the one that sounds senior" but "the one that blocks you every time".

Three combinations come up often in government projects: Information System Security Integration (in construction and upgrade projects), Information System Security Operations & Maintenance (in operations, on-site and annual service projects) and Information Security Risk Assessment (often required together with MLPS — Multi-Level Protection Scheme — related services). Do not pick one at random — look at what the project actually did:

• Integration: you have to point to four steps inside one project — requirement definition, design, implementation, hardening. For a pure supply project with only an equipment list and a delivery acceptance, do not force an integration application; two questions will empty it.
• O&M: you have to show it has been running continuously — the contract period and the number of service report periods must line up, with no long gaps.
• Risk assessment: you have to show the method is stable; two projects should use the same report structure, not a different style for every order.

If one tender names two categories, the lower-effort order is: apply first for the one whose evidence can be told in one pass, and cite the other through a different stage of the same projects. One contract can support two categories, but the passage you point to has to change — for integration point to design and hardening, for O&M point to duty and ticket closure. CCRC's eight categories, one by one sets this out category by category.

Finance route: gather upwards from delivery records

Financial sector buyers tend to split purchases by service content: operations is one package, incident response another, assessment another, development another. So the category should not be decided by "what I want to apply for" but by what you have actually delivered to these clients over the past two years. Go through the contracts and service reports, and the categories whose shape appears will surface on their own.

Two pairings are often overlooked on the finance side:

• Information System Security Operations & Maintenance and Information Security Emergency Response are usually read together. What the client buys is not "someone does inspections" but "someone watches day to day and someone comes when it breaks". Apply for operations only, with incident response completely blank, and the technical discussion goes straight to "who responds when something happens"; apply for incident response only, with no day-to-day operations record, and the question becomes "how do you find problems in normal times". Companies holding both should file routine inspection alerts and incident handling separately rather than merge them into one line.
• In financial scenarios, integration weighs change and rollback. When work is done on production systems, the client cares not about equipment models but about how the window is set, who approves the change, and whether the rollback plan has been drilled. In front of a financial client, a well-written solution is worth less than a clear cutover and rollback record.

Two other categories have to be separated by business shape: Software Security Development is for teams with their own product or doing development for clients — pure distribution or pure deployment does not fit; Information System Disaster Backup & Recovery is evaluated in two directions, resource service and technical service, the first looking at resources and verification and the second at solution and drill organisation, with a different emphasis in the material, so do not apply one to the other. For a first screen of categories, run through the self-match table in how to choose among CCRC's eight categories.

2. Setting the level: start at Level 3 or go higher

On levels the two sides misjudge in opposite directions. On the government route the usual error is pushing for a higher level without need, on the assumption that a higher level cannot hurt; on the finance route it is stopping at the threshold, on the assumption that Level 3 is enough and nothing more is needed. What is actually true is that a level corresponds to a simultaneous rise in project scale and personnel requirements: the higher the level, the more there is to prove, and more does not mean right.

Government route: take the level written in the tender as the starting point

Level on a government project is decided fairly directly: whatever level the tender states is the level to prepare for; where no level is stated, look at how similar projects have been tendered before, or ask the buyer directly. Many companies start at Level 3 because Level 3 already opens a fair number of doors; some tenders with higher requirements state Level 2, and then it depends on whether the project volume you hold can carry it.

There is one practical rule here: a level is not a universal currency; it only works within the matching category and the matching project type. A Level 2 O&M certificate still does not satisfy a tender that names Level 3 integration; conversely, Level 3 O&M bidding for an O&M tender that asks only for Level 3 loses no marks for being a lower level. So the order on the government route is: get the category and the level that open the door, use projects to thicken the evidence, then talk about upgrading — not upgrade first and look for projects afterwards.

Finance route: the level is the ticket in, the margin is the extra

A financial sector purchasing document does not always fix a level threshold, but that does not make the level unimportant — they put the judgement into the technical discussion and the case presentation. At the same Level 3, one company can show a single small project and another several consecutive years of service records, and the sense of capacity margin is completely different.

What this route should prepare is three things beyond the level: whether the team is stable (are there backups for key posts, with no single person as a single point), whether the service is continuous (do the reports form a sequence), and whether cooperation is smooth (can material be supplied on time for audits, inspections and drills). These are also seen in the level review, but in front of a financial client they are often asked about earlier than the level itself.

3. Case evidence: a government procurement project and a financial sector project are not written the same way

This is the section where the fork is clearest. Both routes use the same four kinds of evidence — project, people, premises and tools, system documents — but the government route puts the weight on the compliance of the project evidence and the finance route on the process inside it. One project, written two ways, reads like the work of two different companies.

Government route: prove "this work was taken on by the rules"

The evidence chain on a government project turns on the same entity, complete stages, and a match to the lot. The evaluation committee will not dig down through your technical detail; it checks a few hard facts:

• Contracting entity: is the contract signed by the applicant entity? Signed by a branch or an affiliate, or performed by a branch with social insurance at head office, does not line up.
• Acceptance and settlement: is there a client signature and stamp, a signing date, and does the deliverable list match the contract list? A project with only a contract and an invoice, with every intermediate stage empty, carries little weight in an eligibility review.
• Project name against the lot: the comparable performance you cite has to match the type and content of the tendered project; for a framework agreement without a specific order, get the order in place first.
• Subcontracting: state your own segment. If the security part under a main contractor was delivered by you, draw the boundary in the material — which part was yours, under which subcontract, and who accepted it.

One point is often missed: government projects frequently also require MLPS-related services. Such work is usually not a separate contract but a line item inside an integration or O&M contract. In the evidence, pull it out and explain it separately — which part was done, what was delivered, who confirmed it; and separate what your own company did from results cited from an external body, or neither the responsibility nor the capability can be stated clearly.

Finance route: prove "we have actually worked on the production system"

The evidence chain with a financial client turns on continuity, control and traceability. They care little about contract value and a lot about how you work inside a constrained environment:

• Continuity: service reports have to form a sequence, with the period's incidents, handling results and open issues all written in. A contract for one year of service with reports for two months leaves a gap that cannot be explained.
• Change and rollback: change request, approval, window, implementation record, rollback plan, rollback drill — in a financial setting this chain weighs more than an equipment list.
• Incident timeline: detection, escalation, handling, recovery, review — five points written out. A record that says only "recovered" proves close to nothing.
• Audit and inspection support: when the client's internal audit, external audit or a regulatory inspection asks for material, how fast you supply it and whether it is complete is itself evidence of capability. Support records of this kind deserve their own file.

4. People and teams: how a project manager and security service staff are evidenced

In this section the difference is not "are there enough people" but which capability is being evidenced. The government route has to show "this person can lead a team through the process of a government project"; the finance route has to show "this person knows what may be touched in a production environment, what may not, and how it is recorded".

Government route: the project manager has to be able to explain the process

Delivery on a government project is pushed along by process: initiation, tender, contract, implementation, supervision, preliminary acceptance, trial running, final acceptance, settlement, with audits and inspections in between. If the project manager is not familiar with that rhythm, the project stalls repeatedly at acceptance. So the government route does three things with people evidence:

• The role table has to match real people: project manager, technical lead, implementation staff, quality or security lead — the same names in the same posts should be findable on acceptance forms, meeting minutes and change tickets. A name on the table that cannot be found in the records is a common gap.
• Employment relationship and social insurance with this entity: this is checked by both types of client, but harder in the eligibility review of a government tender — if the person is not with this entity, the project was not done by your team.
• Someone has to be able to attend the defence: some tenders require the project lead to defend or present in person. What is discussed there is not technical detail but "how you organised this project, how you controlled progress, how you handled change". Anyone who has not done that kind of review will show it on stage.

Finance route: the project manager has to understand constraints

With a financial client, a project manager's professionalism shows in three words: window, wording, boundary. The window means changes can only be made in agreed hours; the wording means what is communicated externally, how, and who decides; the boundary means which systems may be touched, which may only be viewed, and which need approval even to view. None of this is useful on a CV; it has to show in the project records.

• Service staff have to deal with two kinds of counterpart: the client's security or technology department, and internal and external audit. The first decides what you do every day, the second decides whether you can prove you did it. A team that can only do the work but cannot supply the material is marked down by a financial client.
• Key posts cannot be single-person single-point: an operation only one person can perform means that person's leave is a risk. Duty rosters, handover documents and dual review are capability evidence, not an HR arrangement.
• Exit needs a handover: accounts, media, documents, access cards, unclosed tickets — handed over item by item and confirmed. This appears again in the next section, because it is the direct basis on which a financial client judges whether a supplier is dependable.

5. Incident response and operations: duty, response and drill records

This section is home ground for the finance route and easily underestimated on the government route. For much of the time a government project does not need you handling incidents every day, but it does need you to hold the line at key periods; a financial client needs you present in normal times, there when it breaks, and able to explain afterwards. The material overlaps, the emphasis does not.

Government route: duty has to reach a shift, a drill has to reach a corrective action

The service shape on a government project is usually "a cycle, reinforced at key periods". So the evidence has to answer two questions: who is present in normal times and who is present at key periods; and has it been drilled, and what did the drill turn up.

• Duty: duty rosters, handover records, inspection plans and inspection records. The reinforced arrangement for key periods has to be visible — who worked extra shifts, for how long, and what was found. A roster on its own, with no handover or inspection records, does not prove anyone was actually on watch.
• Plans: they need an organisation, contacts, incident grading and handling steps. Whether the people named in the plan are live or nominal shows in the contact details and the division of roles.
• Drills: drill plan, drill record, problems found, corrective action, verification. A drill record where everything went smoothly and nothing was found makes people suspect it was written to fit.
• Cooperation on MLPS-related services: who raised the remediation recommendations, who implemented them, who retested — the boundary has to be clear. In government projects this part is often an advantage and is often questioned precisely because the boundary is vague.

Finance route: an incident needs a timeline, a change needs a rollback

Financial clients understand "incident response" more concretely than many industries: not whether a plan exists, but how long it took from detection to recovery, who made the decisions in between, and what changed afterwards. So the evidence here should read like an incident report, not a work summary.

• Incident grading and response: which level triggers which action, who has the authority to grade, who has the authority to cut off or isolate. These have to line up in real incident records, not only in the procedure document.
• Timeline: detection, escalation, grading, handling, recovery, review, each with a time. This is worth more than any concluding description.
• Drills and incidents listed separately: a drill record proves "we prepared", a real incident record proves "we handled it", and neither substitutes for the other. Merged into one line, both lose evidential value.
• Change and rollback: change request, approval, window, implementation, verification, rollback plan and rollback drill. A financial client will ask directly "what if you cannot switch back", and without an answer the item does not stand.
• Logs and traces: how long logs are kept, who can retrieve them, whether retrieval needs approval. This is not an operations detail but the basis on which the client judges whether an incident could be investigated.

6. System documents and confidentiality: NDAs and exit handover

Of the four evidence sets, system documents are the one that is easiest to write as a generic template. They play a different role for each type of client: the government route treats them as part of the eligibility to enter, the finance route as the manual for behaviour during the engagement. The first asks whether you have them; the second asks whether what you wrote can be done.

Government route: write down "who may enter, what may leave"

The site of a government project is often not your own premises: the client's data centre, office area and business systems, possibly with sensitive information and specific management requirements. What the system documents have to cover here is the boundary:

• The NDA has to reach the person: not only one company-to-company agreement, but cover for on-site staff, temporary support staff and subcontracted staff. Whether it was signed, when, and whether it has expired has to be checkable.
• Premises and tool registers: office and service premises, tools used for testing and inspection, equipment carried in and out. The register has to match reality, and each tool has to point to the project and stage where it was used.
• Marking and transmission of information: how project documents are marked, transmitted, to whom, and how long they are kept. Which material may not leave the client site has to be written as an executable action, not a line saying "confidentiality rules are strictly observed".
• The boundary of sub-delegation and subcontracting: whether subcontracting is allowed, to whom, and whether the client's written consent is needed. On government projects this is often written into the contract, and the system documents have to match the contract wording.

Finance route: write down "how the site is left clean on exit"

Financial clients understand confidentiality more in terms of data flows and the lifecycle of access. They are less interested in slogans in your procedure document than in whether you actually did each thing:

• No data taken out: no processing client data on personal devices, no copying production data to a local machine, no pasting client information into external tools (including the various online assistants). These have to be written as explicit prohibitions, with a statement of what happens if they are broken.
• Exit handover checklist: accounts, media, documents, access cards, unclosed tickets, borrowed equipment — handed over item by item with signatures from both sides. This checklist is the direct basis on which a financial client judges whether you will leave a tail behind.
• Confirmation of access revocation: at project end, on staff replacement and on contract termination, how access is revoked in each of the three cases, who confirms it, and within what period. "Revoked promptly" is not a written rule; the trigger conditions and the confirming person have to be stated.
• Disclosure of subcontracting and sub-delegation: which downstream parties are used, what they can reach, and how they are constrained. Financial clients usually ask "who else is in the chain" in more detail than government clients do.

7. Where certification and bid interviews tend to push

A certification audit and a bid review run on two different logics, and the two routes combine them differently. The government route is screen at the bid, verify at certification — the certificate first, then whether you really did the work; the finance route is probe in the discussion, verify at certification — first how you actually work, then back to the material. When preparing, fill the gaps in the order you will be asked, and the difference in effort is considerable.

What the government route gets pushed on

• Which category and which level does the eligibility clause require? Do the category and level on your certificate match, word for word?
• For this comparable performance contract, is the contracting entity the applicant entity? Who signed the acceptance form, and when?
• Does the project name match this lot? If it does not, on what basis is it comparable performance?
• Was this project a main contract or a subcontract? If a subcontract, which segment did you actually perform, and under which agreement?
• Who was the project manager? Does he appear in the acceptance material? Is his social insurance with this entity?
• Of the MLPS-related services in the project, which did you perform and which are results cited from an external body?
• Where the tender requires system documents and tool evidence, can you turn to the matching project in your register on the spot?
• Is there a record of reinforced duty at key periods? What changed after the drill found a problem?

What the finance route gets pushed on

• What did you touch on this system? Do the change ticket, approval, window, implementation record and verification chain into one line?
• Is there a rollback plan? Has a rollback drill been done? Who decides when it cannot be switched back?
• The last incident — how long from detection to recovery? Who graded it, who approved the handling plan?
• Why do the drill records and the real incident records look so alike? Which were drilled and which actually happened?
• How long are logs kept, who can retrieve them, does retrieval need approval? Show me one retrieval record.
• Why are two periods missing from the service reports? Who was serving during that time?
• How many clients does the same person cover at once? Who takes over when he is away? Where is the handover document?
• The project has ended — when was the account disabled? Does the exit handover checklist carry both signatures?

The skeleton both types of client share: four evidence sets across eight categories

Having set out the differences, the shared part has to be stated too. It does not need to be rebuilt per client type, and it would not fail because the client is different — eight categories and two routes all use the same base: project, people, premises and tools, system documents.

• Project: proves "this work was taken on by this company, and finished". Look at the contracting entity, the service content clauses, the delivery process, acceptance and settlement. Break one of the four and the project only counts as half.
• People: proves "it was our people who did it". Look at employment relationship and social insurance, post competence credentials, the role in the project, and whether that role left a trace in the delivery records.
• Premises and tools: proves "there is a place to work and a means to work with". Premises are judged by actual use, tools by register and use records — a tool name and version with no export to show counts as not provided.
• System documents: proves "the capability can be replicated, not held up by one person". Policy, procedure, work instruction and record form — the four layers have to line up, and the forms have to match what is actually used on projects.

This base has three disciplines, and breaking any one of them shows up at verification:

1. One version per data item. Project name, start and end dates, participants and deliverables must be identical in the application form, the project description and the acceptance material. A one-word difference costs time to explain.
2. Each procedure document has to point to the action node of its category. Change and rollback for integration, service level management for O&M, the risk scoring rules for assessment — the clauses they point to differ; writing "we have this procedure" means nothing.
3. When applying for categories separately, do not carry A's narrative straight over to B. The same project can be used under two categories, but the deliverables and stages cited have to be swapped for the part B cares about.

There is a simple self-check for whether this base is sufficient: pick any project and, with this material alone, can you tell the whole story of "who did what for the client, when, with what means, and how the client confirmed it" without adding anything verbally. The link you cannot finish is the one to fill. For how to align the four sets item by item, how to prepare the evidence covers the general method; for the specific material list for Level 3 security O&M, work through the Level 3 security operations qualification line by line.

Common misconceptions: one "assumption" on each side

Government route: assuming "one category covers every tender". This is a costly misjudgement in government work. The category is judged tender by tender: the document names integration and you hold only operations, so you do not qualify; it names operations and you hold only integration, and you still do not qualify. The level is judged the same way — the same certificate may be enough for this tender and one level short for that one. One layer finer is the match between category and project shape: using an operations certificate to explain a project that was a one-off go-live, or an integration certificate to explain a pile of inspection records, explains nothing. The certificate is a general asset; bid eligibility is established tender by tender — once that is clear, you will not discover a missing category the day before bids open.

Finance route: assuming "a higher level is more universal, so go straight for Level 1". A level reflects capability and cases, not intent. The higher the level, the higher the requirement on project scale and personnel at the same time, and if the evidence is not there the file is returned — and what is wasted is not only time but energy that could have gone into projects. The steadier path is: get the level that opens the door, use real projects to thicken the evidence, then move up. What a financial client really cares about is not the line on your certificate but whether you can do the same thing well, over consecutive years, in a constrained environment; the level is simply a handle that makes that judgement easier.

A few more misconceptions common to both sides:

• Assuming "financial clients only look at ISO 27001". The two are not substitutes. CCRC looks at the boundary of your security service capability, ISO 27001 at the system by which you manage information security. Financial clients often want both, and ask at different stages — qualification at procurement, process in the technical discussion, records at audit.
• Assuming "government work only needs the certificate, not the process". The bid looks at the certificate, performance looks at the process. After award the client will look at your people, your records and your response under the contract; the certification audit also looks at your actions by category. The certificate gets you in; the process decides whether you stay.
• Assuming "more cases is better". Ten projects you cannot explain are worth less than three you can take from beginning to end. Verification will pick one and go down through it, and if it breaks the credibility of the whole batch has to be rebuilt.
• Assuming "the entity question can be sorted out later". A contract signed with an affiliate, social insurance with another entity, a project performed by a branch — the later these are handled the more they cost, because projects, people and system documents all have to change with them.
• Assuming "the certificate is the finish line". A certificate has a validity period and has to be recertified under the rules before it expires; new projects in the meantime have to keep being filed. Come back to look for projects only before expiry and you usually find fewer explainable projects than you imagined.

Action list: the shared part first, then the two routes separately

The list below is ordered "shared first, fork second". The way to use it: do the items marked [Shared] first, then work through the [Government] or [Finance] block for your own client mix. Companies working both routes need both blocks, ordered by the share of revenue and the near-term bidding calendar.

• ⬜SharedFix the scope: write in one sentence the service directions, departments and sites the application covers, and confirm for each that there are people, records and traces
• ⬜SharedFix the people: one lead who can move people across departments, plus contacts for projects, technology, quality and security, written down
• ⬜SharedTake stock of projects: keep only projects genuinely undertaken by the company with a complete delivery record, and check the contracting and performing entity for each
• ⬜SharedBuild the base: organise project, people, premises and tools, and system documents under one numbering scheme into a reusable common file
• ⬜SharedOne version of the facts: build a project master table (name, start and end, participants, deliverables) and use it as the single reference throughout
• ⬜SharedSelf-sample: retell one project from the material alone; the link you cannot finish is the one to fill
• ⬜GovernmentCopy the clauses: copy the eligibility clauses of the tenders you plan to bid into a "category × level" frequency table, and set the first application by frequency
• ⬜GovernmentMatch the lots: for each project you intend to bid with, build the "contract – acceptance – settlement" set and confirm the project name and type match the lot
• ⬜GovernmentPrepare the defence: name the project lead who can attend, and rehearse organisation, progress control and change handling until it needs no notes
• ⬜GovernmentDraw the boundary: pull the MLPS-related services in the project out separately, stating what your own company did and what is cited from an external body
• ⬜GovernmentControl entry: NDAs for on-site and subcontracted staff, the premises and tool register, and the register of equipment carried in — all three findable on the spot
• ⬜FinanceLay out the timeline: put operations and incident response records on one timeline, with reports in sequence and the reason stated where a period is missing
• ⬜FinanceTwo piles: file drill records and real incident records separately, and complete the five time points from detection to review in the incident records
• ⬜FinanceFill in change: confirm item by item whether change request, approval, window, implementation, verification, rollback plan and rollback drill exist
• ⬜FinanceBuild redundancy: assign backup staff to key posts, with a roster and handover document that answer "who takes over when he is away"
• ⬜FinanceClear the exit: build the person – project – access – term table, with the exit handover checklist and access revocation confirmation signed by both sides
• ⬜SharedAsk the body: categories, levels, premises and audit arrangements are subject to the tender document as written and the certification body's rules in force

Put the two routes side by side and the conclusion is plain: a government client uses the qualification to subtract — first screen out those who do not qualify; a financial client uses it to add — first confirm whether you can stay at this table for the long run. The same certificate is an entry ticket in the first setting and an opening topic in the second. Work out which one you mainly face, and the preparation will not start from the wrong category, and you will not be stopped in a defence or a technical discussion by a single "so who actually does this, and how is it recorded".

▍Not sure which route to prepare for? Leave a comment noting "client route", send us your main business, main client types and near-term bidding plans, and we will send back an evidence order list for each of the two routes.