How do you maintain SOC 2 compliance continuously?

SOC 2 Type II itself is still a periodic examination (typically a 3 to 12 month reporting period), but the underlying controls can be maintained continuously using SOC 2 automation tools (Vanta, Drata, Secureframe, Hyperproof, Sprinto, OneTrust) that collect evidence continuously, flag control failures as they happen, and keep the organisation in audit-ready state between examinations. Continuous maintenance of the controls shortens the gap between a control failure and detection, which both reduces risk and makes the next SOC 2 examination less expensive.

What is compliance as code vs policy as code?

Policy as code is the mechanism: writing policies in a machine-readable format that can be versioned, tested, deployed and evaluated by automated tools. Compliance as code is a specific use of that mechanism: using machine-readable policies and automated checks to operationalise compliance requirements, so that compliance obligations are enforced automatically in the delivery pipeline. Open Policy Agent and HashiCorp Sentinel are policy-as-code engines; a compliance-as-code programme uses them, often alongside other automated-evidence sources like dependency scanning, to meet specific regulatory or sectoral requirements.

What is compliance drift?

Compliance drift is the divergence over time between a system's actual state and the requirements or baseline it is expected to satisfy, caused by changes to the system, its dependencies or configuration, or by changes to the requirements themselves. It has two sides: implementation drift (reality moves while rules stay fixed) and requirement drift (rules move while software stays fixed). Both are real. Most compliance tooling handles one well and the other poorly.

Which approaches do teams use to manage compliance, and how do they compare?

Five approaches are common: compliance as code in the delivery pipeline, manual release audits, formal assurance programmes such as SOC 2 and ISO 27001, continuous control monitoring of the deployed environment, and external shipped evidence. They differ in what they observe, what they catch, what they miss, how feedback arrives, and which kind of drift they handle best. Mature programmes combine them rather than selecting one, because each covers a different source of evidence.

Does continuous compliance replace manual audits or formal assurance?

No. Continuous compliance improves the cadence and depth of evidence collection, but it does not remove the need for formal independent assurance over organisational controls (SOC 2, ISO 27001) where that assurance is required by customers, regulators or contracts. It also does not remove the need for human judgement where a requirement is contextual or interpretive. The mature view is that automation and continuous monitoring reduce the cost and risk of the periodic human and third-party work, rather than replacing it.

Where does external shipped evidence fit alongside the other approaches?

External shipped evidence is independent artefact-level observation. It is strongest for questions that can be answered from the released software itself, especially where other approaches struggle (mobile apps distributed through app stores, requirements that drift while the binary does not, verification that what actually shipped matches what the pipeline said would ship). It does not replace the other four; it fills a gap they leave open.

Continuous Compliance: Five Approaches Teams Use

Compliance drift is the divergence over time between a system's actual state and the requirements or baseline it is expected to satisfy, caused by changes to the system, its dependencies or configuration, or by changes to the requirements themselves. The second half of that sentence is the part most compliance writing misses. Software changes, and the rules governing that software change too. A system that was compliant on Monday can be non-compliant on Friday without a single line of code shipped between them.

Teams generally attack this problem from five different positions: encode rules in the delivery pipeline, review releases manually, obtain formal independent assurance, monitor deployed controls continuously, or inspect evidence from the software that actually shipped. Each position catches different things. Each misses different things. Mature programmes combine them rather than choosing one.

This article walks through the five approaches, compares them on what they observe and the drift they catch, and ends with a short section on how the Appnalysis evidence layer sits alongside them. It is about how teams manage compliance in practice, not which rules apply to a specific app. For the latter, the hidden regulation pyramid covers the five regulatory layers that any mobile app sits under.

Key takeaways

Compliance drift has two sides: implementation drift (reality changes, rules fixed) and requirement drift (rules change, software fixed)
The five approaches each observe a different source of evidence and catch a different kind of drift
Formal assurance, including SOC 2 and ISO/IEC 27001, provides periodic independent assurance; it is not the same as continuous compliance
Continuous control monitoring, as NIST and FedRAMP define it, is a distinct discipline that watches the deployed environment after release
External shipped evidence is the independent artefact-level view, particularly useful for mobile apps distributed through app stores

What is continuous compliance?

Continuous compliance is the practice of repeatedly assessing whether systems, software, controls and evidence continue to satisfy applicable requirements as both the technology and those requirements change. Unlike a one-off compliance assessment, continuous compliance shortens the interval between a change in compliance state and the organisation detecting it. In practice, continuous compliance monitoring is the cadence at which this assessment runs: ongoing, automated where possible, and surfacing changes close to real time rather than at an annual review.

The term aligns with how NIST SP 800-137 describes information security continuous monitoring, and with how the PCI Security Standards Council frames the shift from annual-only assessment to year-round compliance work. Both treat continuous as a cadence and a discipline, not a product.

Compliance as code in the pipeline

Compliance as code puts machine-readable policies into the CI/CD pipeline so that non-conforming changes can be caught, blocked or flagged automatically before they ship. Open Policy Agent (OPA) uses Rego to enforce policies across CI/CD, Kubernetes admission controllers, infrastructure provisioning and other environments. HashiCorp Sentinel does the same inside the HashiCorp stack. Both let an organisation version, test and deploy its compliance policies like software.

One conceptual distinction is worth making explicit. Policy as code is the mechanism. Compliance as code is the use of machine-readable policies and automated checks to operationalise compliance requirements.

Dependency scanning sits alongside policy enforcement as a different source of automated evidence. OWASP Dependency-Check identifies known disclosed vulnerabilities in dependencies. Software composition analysis tools (Snyk, Sonatype, GitHub Dependabot) do similar work for a wider range of findings. These scans produce signals the pipeline can act on, independently of whatever policy framework surrounds them.

What it catches: source, infrastructure as code, configuration and proposed deployment issues, before shipment. Encoded violations that match current rules.

What it misses: anything the organisation has not encoded. Rules that change after the policies were written. Runtime behaviour of the deployed system. Issues that emerge in configurations outside the policy scope.

Maintenance model: internal rule corpus. The organisation owns the mapping from requirement to encoded check, and keeps it current.

Feedback speed: seconds to minutes, inside the pipeline.

The most important weakness: the encoded rule can be perfectly enforced and still be wrong or stale. That is requirement drift in action, and no amount of policy enforcement catches it unless someone updates the policy.

Manual release audits

Manual release audits put a human review step in front of release. A reviewer, or a committee, checks the release package against a set of expectations and signs off. The reviewer may use checklists, run specific tests, inspect specific artefacts, or exercise judgement about things that are hard to encode mechanically.

The advantage of manual review is semantic and contextual judgement, not legacy process. Some requirements are contextual, interpretive, or deliberately subject to human approval. Human release gates remain common where requirements require judgement, documented sign-off or evidence that cannot be evaluated mechanically.

What it catches: nuanced and non-machine-readable issues. Issues that depend on business context, user impact, or regulatory interpretation. Problems a checklist author did not anticipate.

What it misses: between-review changes, scale problems, and anything the reviewer does not have time to look at properly. Reviewers under pressure cut corners, and the review becomes a signature rather than a check.

Maintenance model: human expertise, supported by checklists.

Feedback speed: hours to days, at review time.

The disadvantages are frequency, throughput and reproducibility of judgement. Two reviewers can reach different conclusions on the same release. The same reviewer can reach different conclusions on different days. Mature manual-review programmes mitigate this with structured checklists and documented sign-off, but the trade-off never fully disappears.

Formal assurance programmes and SOC 2 automation

This bucket covers independent third-party assurance obtained through periodic examination of an organisation's controls. It is often loosely called "certification" but the terminology inside the industry is more specific.

SOC 2 is an AICPA examination of a service organisation's controls. The CPA firm issues an assurance report, not a certificate. Type I reports describe control design at a point in time. Type II reports assess operating effectiveness over a defined period. SOC 2 automation tools (Vanta, Drata, Secureframe, Hyperproof, Sprinto, OneTrust) collect the evidence SOC 2 reporting needs and keep it in audit-ready state continuously.

ISO/IEC 27001 is a certifiable information security management system standard. An accredited certification body issues certification against the ISO/IEC 27001 requirements, which focus on continual improvement rather than a one-day snapshot. ISO/IEC 27701:2025 is now a standalone Privacy Information Management System standard, which can be certified independently of ISO/IEC 27001.

PCI DSS uses assessment and validation mechanisms including Reports on Compliance, Attestations of Compliance and Self-Assessment Questionnaires. The PCI Security Standards Council explicitly warns against treating unofficial "PCI DSS compliance certificates" as evidence of compliance.

HITRUST provides an assurance and certification framework often used in US healthcare, with continuing requirements rather than a one-day snapshot.

What it catches: organisation-level and control-environment issues inside the assurance scope. Design flaws in controls. Operating-effectiveness problems over the examination period.

What it misses: fine-grained release-state issues outside the defined scope. Changes between assurance cycles. Specific product behaviour the assurance programme did not look at.

Maintenance model: framework plus audit programme. Continuous evidence collection where SOC 2 automation is in use.

Feedback speed: weeks to months, depending on cadence and findings.

Formal assurance is periodic and scoped. It can provide strong independent assurance over a defined date, period, system or control environment, but it does not automatically provide release-by-release or near-real-time visibility into every changed artefact. The right summary of the trade-off is high trust, broad organisational scope, slower feedback cadence.

Continuous control monitoring in production

Continuous control monitoring observes the deployed system after release. It repeatedly checks configuration, infrastructure and operating controls against defined baselines, making it particularly useful for detecting post-release configuration drift and changes made outside the normal delivery pipeline.

NIST SP 800-137 defines Information Security Continuous Monitoring (ISCM) as a discipline aimed at maintaining ongoing awareness of information security, vulnerabilities, threats and effectiveness of deployed security controls. In the GRC industry, this discipline is commonly called continuous controls monitoring (CCM) and vendor glossaries treat it as a distinct category. FedRAMP uses continuous monitoring as the basis for ongoing authorisation decisions on cloud service providers.

Commercial cloud platforms implement the same model. Microsoft Defender for Cloud continuously assesses Azure, AWS and GCP resources against standards and controls, combining automated assessments with manual attestations and evidence, and triggering automated workflows when assessments change. AWS Config evaluates resource configurations and retains compliance scores and timelines through conformance packs so organisations can see compliance-state changes over time.

The conceptual distinction from compliance as code is important. Pipeline controls evaluate what you intend to deploy. Continuous control monitoring evaluates what is actually deployed. OPA, Sentinel and pipeline policy checks run before a change reaches production. Defender for Cloud, AWS Config, and other continuous-monitoring tools run against production itself.

What it catches: deployed-state configuration drift, infrastructure changes, control effectiveness in the running environment, changes made outside the normal pipeline.

What it misses: requirements that have not been mapped into a monitored control. Many artefact and store facts that live outside the cloud environment. Issues in software distributed to end-user devices (mobile apps, desktop software) that the cloud monitoring never sees.

Maintenance model: monitored baselines. The organisation defines what "in control" looks like and the monitoring tool watches for divergence.

Feedback speed: minutes to hours in a running cloud environment.

Continuous control monitoring often has much greater visibility into cloud infrastructure than into a consumer mobile binary distributed through an app store. That gap is where the fifth approach comes in.

External shipped evidence

External shipped evidence is compliance evidence derived independently from the software artefact and associated metadata that users can actually obtain, rather than from the developer's source repository, internal controls or claimed build state.

For a mobile app, the shipped artefact is the binary in the App Store or Play Store. For a web product, it is the code and configuration actually served to users. For an API, it is the responses the API actually returns in production. The common feature is that the evidence is observable from outside the organisation's own tooling.

OWASP's Mobile App Security guidance recommends analysing the final built binary rather than assuming that a secure development process guarantees a secure shipped result. The same principle applies at the compliance level: observable artefact-level evidence answers questions that source-level and pipeline-level controls alone cannot.

What it catches: properties of what actually shipped. Observable facts about the deployed artefact that cannot be derived from the source repository alone. Changes between shipped versions that pipeline controls never saw.

What it misses: internal governance and inaccessible runtime facts. Server-side behaviour the external observer cannot reach. The organisation's own control environment. Any fact that cannot be observed from outside.

Maintenance model: external evidence and rule mapping. The provider owns much of the mapping from requirement to observable test, which transfers rule-maintenance burden away from each individual engineering organisation. The burden moves, it does not vanish.

Feedback speed: hours to days, or continuously, depending on release cadence.

External shipped evidence does not eliminate rule maintenance. Any system deciding whether evidence satisfies a changing requirement needs an up-to-date interpretation of that requirement somewhere. OPA can load new policy bundles dynamically, but someone still has to maintain those policies. Apple and Google continually modify the policies against which mobile products are evaluated. The external-evidence model moves the maintenance work outside the customer's pipeline, which is where it is most useful.

five-approach continuous compliance comparison matrix showing what each approach observes, what drift it catches, and its feedback speed

The five approaches at a glance

Approach	What it observes	What it catches	What it misses	Maintenance model	Feedback speed	Drift strength
Compliance as code	"Source, config, IaC, proposed deployment"	Encoded violations before shipment	"Unencoded or stale rules, later runtime changes"	Internal rule corpus	Seconds to minutes	Implementation drift at change time
Manual release audits	Release evidence plus contextual information	Nuanced and non-machine-readable issues	"Between-review changes, scale problems"	Human expertise plus checklists	Hours to days	Both drifts at release time if reviewer notices
Formal assurance	Organisation plus defined control scope	"Governance, control design and operating evidence"	Fine-grained release-state outside scope	Framework plus audit programme	Weeks to months	Both drifts across the assurance period
Continuous control monitoring	Deployed controls and configuration	Runtime and configuration drift	"Unmapped requirements, many artefact or store facts"	Monitored baselines	Minutes to hours	Strong on implementation drift
External shipped evidence	Released artefact plus externally observable metadata	Properties of what actually shipped	Internal governance and inaccessible runtime facts	External evidence and rule mapping	Hours to days or continuously	Strong on requirement drift against unchanged artefacts

Each row describes a different epistemic source: where the organisation's compliance confidence actually comes from. That is why the five approaches are complementary rather than ranked. Pick the subset that gives you the evidence sources you need, in the cadences you need them.

The compliance drift problem

Compliance drift has two sides, and most tooling only handles one.

Implementation drift is when the requirement stays fixed and reality moves. A deployed system was in a compliant state, something changed in the environment, and now it is not. This is what AWS and Microsoft documentation describes when they talk about compliance drift. In infrastructure, implementation drift is usually called configuration drift, and most cloud-platform continuous-monitoring tooling is built around detecting it. Continuous control monitoring is strongest here.

Requirement drift is when the software stays fixed and the required position moves. A binary that was compliant under rule set A is now subject to rule set B, and nobody rebuilt the binary. This is the kind of drift that compliance-as-code catches only after the encoded policies have been updated, and that formal assurance catches only when the next assurance cycle picks it up. External shipped evidence is particularly strong here: an unchanged artefact can be re-evaluated against updated requirements without any change to the artefact itself.

A third concept worth naming briefly, without turning it into another term to track, is evidence drift. Evidence remains on file after the state it once represented has changed. The paperwork says the organisation is compliant. The system no longer is. Audit teams, QA teams and compliance teams all encounter this and all have different names for it.

The practical implication: the question "is this system compliant?" has at least two answers depending on which side of drift the asker is interested in. A good continuous-compliance programme can answer both.

two-lane drift diagram showing implementation drift and requirement drift as separate timelines from compliant to needs-re-evaluation

The rulebook can drift too

Compliance drift is often treated as something that happens to a system. It also happens to the rulebook. Someone has to notice that the governing requirement changed.

Mobile makes this particularly visible. Google regularly updates its Developer Programme Policies and publishes policy deadlines for developers to prepare app updates. Apple similarly revises its App Review Guidelines and developer programme terms, while developers are responsible for keeping App Store privacy disclosures accurate and up to date as practices change.

The distinction matters. Detection tells you whether reality matches the rule. Regulatory change management tells you whether you are still testing against the right rule. The first is a tooling question. The second is an organisational discipline, often sitting between legal, compliance and engineering, and it is what feeds every one of the five approaches above.

Build reproducibility, provenance and shipped evidence

Build reproducibility and compliance are related but not the same thing. The Reproducible Builds project defines a reproducible build as one where the same source code, build environment and instructions can recreate bit-for-bit identical specified artefacts. SLSA provenance is an authenticated attestation that a particular build platform produced an artefact from a defined build process. Neither on its own proves compliance.

A clean way to separate what each answers:

What was built? → artefact inspection
How was it built? → provenance (SLSA)
Can somebody independently recreate it? → reproducible build
Do those properties, processes and controls satisfy an applicable requirement? → compliance work, drawing on the above and more

None of those questions alone answers whether the artefact satisfies every applicable regulatory obligation. Compliance work still has to connect the technical facts to the requirements. The five approaches above are five different ways of doing that connection.

How Appnalysis fits

Appnalysis occupies the external shipped-evidence layer. It is most useful where the compliance question can be answered from observable properties of the distributed app, its dependencies, metadata or other independently obtainable evidence. It sits alongside pipeline policy, human review, organisational assurance and runtime control monitoring rather than replacing them.

A team might use OPA to stop a non-conforming change, Defender for Cloud to observe deployed controls, a SOC 2 report to provide organisational assurance, and Appnalysis to independently assess what users can actually obtain from the store. Those are complementary evidence sources, not mutually exclusive products.

For teams building with AI-assisted development, Appnalysis can be added as an agent into Claude Code, Codex and other AI coding workflows, so the assistant can reason against observable shipped-app evidence during development rather than generating code without that context. For the broader pattern of specialist knowledge in AI coding workflows, Your AI Coding Agent Only Sees Half the Picture covers the model.

Honest limits apply. Observable shipped evidence can establish facts about the released artefact, but it cannot establish every fact about internal organisational processes, cannot necessarily observe server-side behaviour, and does not replace SOC 2 reports, ISO certification or the organisation's own control environment. For teams already running compliance automation tooling, external shipped evidence sits alongside it. For teams running a mobile app audit on their own inherited product, it is the owner-inward application of the same evidence source. For teams dealing with accumulating compliance debt, it is one of the detection mechanisms.

The /product and /agencies pages have more on how different teams use it.

Closing

Continuous compliance is not a single technology or certification state. Teams can prevent violations before release, apply human judgment at release, obtain independent assurance over organisational controls, monitor live systems after deployment, and independently examine what actually shipped. The more frequently software and requirements change, the more useful it becomes to combine those vantage points rather than rely on one of them alone.

This connects to how software is growing up: the industry is accumulating distinct evidence disciplines rather than converging on one. Each one answers a question the others cannot. The teams who manage compliance well are the ones who treat the five as a layered system rather than a competition.