What CREST SOC accreditation assesses

Most cybersecurity accreditations tell you an organisation has written the right policies. CREST Security Operations accreditation is more specific than that. It examines how a security operations centre is run day to day. This includes which tools it uses and who approved them, how analysts are trained, how shifts are managed, and what happens when a client leaves.

If you are choosing between managed SOC providers, the distinction is an important one. This is a guide to what the standard assesses, and the questions it should prompt you to ask your existing or potential security partners.

What CREST accredits

CREST is an international accreditation body for cybersecurity service providers. Accreditation is awarded against a published standard, and the current Security Operations Accreditation Standard is version 1.0.

The standard was developed with CREST's partners, members and regional councils, and approved by a focus group of practitioners drawn from security operations providers across the UK, Europe and Asia. It is a standard written by people who run SOCs, which is part of why the emphasis is operational rather than theoretical.

Its stated purpose is to establish a structured framework that organisations must follow to achieve accreditation in delivering SOC services. That said, it does not prescribe how a SOC should work. It sets out what has to be consistent, secure and efficient, and leaves the method to the provider.

The six domains

The standard is organised into six domains, each containing controls, objectives and numbered assessment requirements that set out the evidence an organisation has to produce. CREST publishes the standard itself, and the full control-by-control detail is available from CREST. What follows is a buyer's-eye summary of what each domain is concerned with.

Domain 1: Governance of core technical capabilities

How tools are chosen, reviewed, maintained and secured, including anything built in-house. The provider has to show records of the evaluation process, who approved each tool and against what criteria, documented review schedules and their outcomes, and maintenance and patch records.

This domain also covers automation and AI governance, which is worth pausing on. Almost every provider now describes its platform as AI-driven. This is the standard asking who governs that, and on what basis.

Domain 2: Organisation capability

Whether the provider has the capacity and infrastructure to deliver. Alongside the expected material on threat intelligence, attack classification and threat enumeration, this domain covers capacity management, site security, shift management and fatigue control.

Domain 3: People

This is all about the SOC team itself - how it is structured, how analysts are trained and developed, and how the function is managed. The standard includes an annex describing the roles a security operations provider is expected to have.

Domain 4: Processes and guidelines

Whether there is a documented and repeatable SOC management methodology, whether it is reviewed on a schedule, and whether incident response is rehearsed through simulations rather than assumed to work.

Domain 5: Preparation, planning and scoping

This covers the commercial and legal groundwork, including scope definition, roles and responsibilities, client engagement, regulatory compliance, service deliverables, communication management, secure data management, legal authorisation, data sovereignty and jurisdictional compliance.

Domain 6: Managing the SOC service

This focuses on the lifecycle of the service - onboarding and deployment, monitoring and analysis, managing alerts and events, threat detection, SLA monitoring, communication, offboarding, and third-party risk management.

Four things buyers do not expect to find in CREST

Most summaries of CREST accreditation list governance, people, technology and process, which is true of almost any standard. These four are more specific, and often more useful when you are comparing providers.

Analyst fatigue is assessed. Shift management and fatigue control sit inside Domain 2, alongside capacity management and site security. This indicates that CREST has decided that how tired your analysts are is a matter of service quality, not just staff welfare. Anyone who has worked a night shift understands why. Detection at 2am in the morning is done by a person, and a person on their fourth consecutive night shift misses things that the same person would catch on a Tuesday afternoon. The standard treats rota design as part of the control environment, which is unusual and, once you have seen a tired SOC, makes a lot of sense.

Offboarding is a control. Domain 6 assesses how a provider hands your service back at the end of a contract, including the documentation you receive, what happens to your data, and how the transition is managed. Procurement processes concentrate almost entirely on the other end, and the questions that are most important tend to arrive years later, at the point where somebody wants to change supplier or bring the function in-house. A provider that has evidenced its offboarding process to an assessor has already answered the question you would otherwise be asking under pressure.

Data sovereignty is explicit. Domain 5 covers jurisdictional compliance and where data is held and processed. For a regulated organisation this is frequently the constraint that decides the shortlist before anyone has looked at detection capability, and it is rarely as simple as the country on the contract. Alert data, log storage, the location of the analyst reading it and the backup site can all sit in different jurisdictions. The standard requires that a provider can account for all of them.

What accreditation does not tell you

Accreditation should be seen as a baseline, not a ranking. It confirms that a provider meets a defined standard consistently. It cannot tell you

• Whether the service suits your estate. A SOC accredited to run enterprise environments may be poorly matched to a fifty-person business, and the reverse is also true.
• Who will actually work on your account. The standard assesses training and competence across the team, not the seniority of the analysts monitoring your environment.
• What the service costs, or how it is priced. Nothing in the standard addresses commercial terms.
• How the provider behaves under pressure. Incident response simulations are assessed. Your incident is not.

None of the diminishes the value of the accreditation, but it does mean that it should be treated as the filter used to draw up a shortlist rather than being the deciding factor.

Using it when you are choosing a provider

In many ways, the domains double as an agenda. If you are writing a tender or preparing for supplier meetings, the standard gives you a set of questions to work from.

• Which tools do you use, who approved them, and when were they last reviewed?
• How do you govern automation and AI in detection and response?
• What are your shift patterns, and how do you manage analyst fatigue?
• How often do you rehearse incident response, and what did the results of the last simulation change?
• Where will our data be held, and under whose jurisdiction?
• What happens at the end of the contract, and what do we get back?

A provider that holds the accreditation will have evidence for all of these, because it has already been submitted in order to achieve the accreditation.

Talanos and CREST

Talanos Cybersecurity holds CREST Security Operations accreditation. We went through the assessment because the questions above are often the ones our clients ask, and an independent standard is a better answer than our own assurances.

If you are comparing SOC providers and would like to discuss what any of this means for your organisation, get in touch.

Read on

Explore more about our services and approach:

• Managed Security Operations Centre
• Managed Detection and Response
• Dark Web and Deep Web Intelligence
• Cloud Security Assessments