Most DCC guidance assumes the reader has an office with a perimeter firewall and a fleet of laptops. For modern cloud-native and SaaS suppliers that model does not apply. The perimeter is someone else's (the cloud provider's), the fleet is a mix of personal laptops and ephemeral containers, and "the office" is Slack. DCC still applies, and the scheme has specific expectations for cloud-native suppliers - but the evidence looks fundamentally different from the traditional audit template.
This guide walks through how to scope DCC for a cloud-native supplier, what evidence the assessor is actually looking for in a cloud context, and how platform gap analysis materially reduces the engagement effort at L1.
For this guide a "cloud-native" supplier is one with:
This pattern covers modern consultancies, analytics firms, software product companies, data science teams, and many mid-sized specialist defence suppliers.
The first and most important scoping decision is: what are the in-scope systems?
The common mistake is to define the scope too narrowly ("only the MOD project Slack channel and the MOD project GitHub repo"). Assessors rarely accept very narrow scopes because MOD data rarely stays contained - it flows into the engineer's laptop, into the code that processes it, into the logs the code writes, into the backup of those logs, into the SSO platform authenticating the engineer, into the CI/CD pipeline that built the code. All of these are legitimately in the attack surface.
A defensible scope for a cloud-native supplier typically covers:
The supplier register covers the SaaS providers underneath this scope: Microsoft or Google, the cloud provider(s), GitHub, Slack, the observability platform, the CI/CD tooling.
Firewalls. Cloud-native suppliers evidence this via cloud security groups, VPC configurations, and WAF rules - not a perimeter firewall. Evidence: current security group configurations exported from AWS/Azure, documented ruleset justifications, evidence of periodic review. A cloud security group with 0.0.0.0/0 on SSH or RDP is a mandatory finding.
Secure configuration. Evidence: infrastructure-as-code repositories (Terraform, CloudFormation, Bicep) showing secure baseline configurations, CIS benchmark adherence for compute resources, CIS or CSA STAR for the cloud provider, secure container base images if using containers, documented secure baseline for SaaS administrative settings (M365, Google Workspace, GitHub).
Security update management. Evidence: cloud-native patch cadence for OS images, base container image rebuild cadence, SaaS provider uptime and patching (the provider's responsibility, evidenced by their certifications), evidence that your own code dependencies are updated regularly (Dependabot or equivalent reports, SBOM generation).
User access control. Evidence: SSO configuration with MFA enforcement, conditional access policies, IAM audit evidence showing principle of least privilege, periodic access review evidence, privileged access separation (admin accounts separate from day-to-day accounts), break-glass account handling.
Malware protection. Evidence: MDM policy showing AV/EDR enforcement on endpoints, mail gateway evidence (attachment scanning, link protection), where applicable WAF evidence for public-facing services. For fully managed SaaS (like Microsoft 365) the provider's attestations cover a substantial portion.
Cloud-native suppliers must be able to articulate clearly what they are responsible for versus what the cloud or SaaS provider is responsible for. This is the "shared responsibility model" conversation, and assessors test it.
For AWS, Azure, and GCP the provider is responsible for the physical data centre, the hypervisor, the underlying network, and the availability of the service. The customer is responsible for configuration of the service they use - how IAM is set up, how security groups are defined, how data is encrypted, how logs are captured, how access is managed.
For SaaS providers like Microsoft 365 the provider is responsible for the application availability, the underlying infrastructure, and significant configuration security. The customer is responsible for tenant-level configuration (conditional access, MFA, data loss prevention, retention policies), user identity, and the security of data the customer chooses to put in the service.
Evidence that this model is understood: a documented shared responsibility matrix covering each cloud and SaaS provider the supplier uses, mapping which side is responsible for each control area. A short document (often 2-3 pages) is sufficient.
For L1 engagements Fig runs its technology platform against the supplier's in-scope cloud infrastructure and SaaS configuration. The platform performs automated gap analysis covering:
This is a material differentiator versus pure audit-based Certification Bodies, because cloud-native suppliers typically have a long tail of minor misconfigurations that would otherwise surface as findings during formal assessment. Running the platform first means those findings are remediated quietly before the assessor ever looks at the submission.
The platform is worth approximately £4,200 per annum as a standalone subscription and is included in Fig's L1 fee for the duration of the engagement.
The governance artefacts - Information Security Policy, Incident Response Plan, ISMS - look structurally the same in a cloud-native context, but the content is different. Cloud-native-specific considerations:
Information Security Policy. Must address remote working, BYOD, cloud platform usage, SaaS tool usage, and acceptable use of personal accounts for work purposes.
Incident Response Plan. Must address cloud provider incident notifications (how you are notified if AWS or Microsoft has an incident affecting you), SaaS provider incidents (data breach notification from a third party you use), code supply chain incidents (compromise of an open-source dependency or CI/CD tool).
Data handling policy. Must address where customer data can be stored, cross-border transfers, retention and destruction in cloud contexts, encryption at rest and in transit.
Access control policy. Must reflect SSO and federation, not traditional on-premise AD.
Change management. Must reflect CI/CD, infrastructure-as-code, feature flags - not a traditional CAB.
Unclear shared responsibility. The supplier claims to rely on "AWS security" without being able to articulate what AWS is and is not responsible for in their specific architecture.
Overly permissive IAM. Broad-use service accounts, long-lived access keys, lack of role separation between production and development.
SaaS tool sprawl. Dozens of SaaS tools in use across the organisation, many onboarded without security review, with no documented register.
Public GitHub repositories leaking secrets. Surprisingly common and a rapid disqualifier at assessment.
No evidence of access review. Cloud-native suppliers often use SSO excellently but never periodically review who has what access.
Missing MFA on privileged accounts. Particularly breakglass or root accounts for cloud providers.
Log retention gaps. MOD data handling typically requires logs to be retained for 12 months minimum; cloud-native defaults are often 30-90 days unless explicitly configured otherwise.
The scheme is proportionate. A four-person AI consultancy hosting client work on AWS does not need an enterprise-grade ISMS. What is expected:
That evidence pack satisfies L0 or L1 at small cloud-native scale.
Cloud-native suppliers benefit disproportionately from an L1 engagement with a technology-platform-equipped Certification Body, because the platform surfaces the long tail of configuration findings before formal assessment. For L0 engagements the content is more documentary but the principles above still apply - cloud-specific scoping and evidence rather than applying a traditional office-network template.
At L1 and above DCC assessments include interviews with named roles. This guide walks through the specific questions assessors typically ask the incident response lead, the IT/technical lead, and the senior governance attester - and what good answers look like.
DCC Level 1 is substantially more involved than Level 0 and is where most suppliers underestimate the effort. This guide walks through a practical six-phase preparation approach covering scoping, governance, technical controls, platform gap analysis, mock assessment, and submission.
The honest answer to "how long does DCC take" depends more on the supplier's starting posture than on the Certification Body's turnaround. L0 can complete in under three weeks for a prepared organisation. L1 is a six to twelve week engagement. This guide walks through both, with the specific factors that lengthen or shorten each phase.