Compliance programme automation,
readiness you can point at.

• Requirements mapped to a shared control library: one control, many frameworks
• Readiness derived as (met + half of partly met) ÷ applicable requirements
• Not applicable only with a written justification; unmapped requirements count as not met
• Control status from connectors, the SDK in CI and uploaded evidence, each with a test date
• Policy register with templates per framework, draft-review-approved status and approval logged to the audit trail
• Separate production, staging and development environments under one account
• Scoped auditor workspace and a public trust page from the same scores

Compliance programme automation is software that keeps the state of a framework such as SOC 2, ISO 27001 or the DPDP Act current without a person updating a spreadsheet: requirements are mapped to controls, controls are tested by integrations and pipelines, and the readiness figure follows from the results.

The test of whether it is real automation is simple: can anyone move the score without changing a control? Here they cannot. A requirement maps to shared controls, controls carry dated results, and readiness is computed from the far end of that chain. The table that holds the score is protected against direct writes.

1. Enable a framework. Choose SOC 2, ISO 27001, DPDP, GDPR or another supported regime. Its requirements arrive already mapped to the shared control library.
2. Connect the sources of truth. Read-only connectors for AWS, Google Cloud and GitHub, the SDK in your CI pipeline, and uploaded evidence each produce dated results against controls.
3. Scope what does not apply. Mark a requirement not applicable with a written justification. It leaves the denominator, and the justification is what the auditor reads.
4. Work the gaps. Failing and untested controls become the work list. Fixing one control moves every requirement mapped to it, in every framework you run.
5. Keep the policy register current. Track each policy from draft through review to approved, with its version and approver, and the approval written to the audit trail.
6. Hand the result to the auditor. Give the auditor a scoped, read-only workspace for the framework and period, and publish the same readiness on your trust page if you choose.

Because most frameworks ask for the same handful of things in different words. Multi-factor authentication, access reviews, change approval, logging, encryption, vendor review and incident response appear in SOC 2, ISO 27001, the DPDP Rules and most sector frameworks. Testing each once and mapping the result to every requirement it satisfies is what stops the second framework costing as much as the first.

The library maps each requirement to the controls that answer it, and the cross-framework mapping pages publish those mappings so you can check them. When a control fails, every requirement mapped to it moves at once, in every framework.

A requirement is partly met when some of the controls mapped to it pass and others fail or have not been tested. Counting it as half is a deliberate middle: counting it as met overstates readiness, and counting it as not met hides real progress from the team doing the work.

Two other states are kept honest. A requirement can be marked not applicable only with a written justification, and it then leaves the denominator. A requirement with no control mapped to it yet is not modelled and counts as not met, so a framework never reaches 100% by having requirements nobody looked at.

For a small SaaS company starting with working engineering practices, three to six months to readiness is common; a SOC 2 Type 2 report then needs an observation period, often three to twelve months, before the auditor can issue it. The time goes into the gaps, not the paperwork: access reviews nobody runs, logging nobody keeps, vendors nobody reviewed.

Automation shortens the part that is about knowing where you stand. It does not shorten the observation period, and it does not make a missing control pass. See SOC 2 Type 1 vs Type 2 for how the periods work.

An auditor tests whether each control was designed to meet the requirement and, for SOC 2 Type 2 or an ISO 27001 surveillance audit, whether it operated throughout the period. They sample: twenty-five changes from the year, the access review from each quarter, three incidents. Evidence that exists only for the day of the audit fails the sample.

That is why control results here carry dates, evidence items expire, and a control tested quarterly shows as stale when the quarter passes without a result. The record has to cover the period, not the afternoon.

Run them on one control set and plan the audits around shared evidence. ISO 27001 adds requirements SOC 2 does not have, chiefly the management system: scope, risk assessment method, Statement of Applicability, internal audit and management review. SOC 2 adds its own emphasis on the system description and criteria such as availability or confidentiality if you include them.

The shared controls are tested once. The ISO-only parts live in the risk register and the Statement of Applicability, and SOC 2 vs ISO 27001 covers which to do first.

• The scope: which systems, teams and locations are in, and why anything is out
• For each requirement, the control that meets it and the evidence it operated across the period
• Justifications for anything marked not applicable
• Approved, current versions of the policies, with who approved them and when
• The risk assessment and how its results chose the controls (ISO 27001 clause 6.1)
• Exceptions: what failed, when, and how it was fixed

• It does not write your policies; it keeps the register, status, versions and approvals
• It does not make a control pass. Readiness rises only when control results do
• It does not replace the auditor or issue a report or certificate
• It does not shorten a SOC 2 Type 2 observation period
• Frameworks whose requirements are not fully modelled say so on coverage rather than showing a flattering score

This is one engine of eleven on a single control graph, which is why a result produced here reaches every framework that asks for it instead of being gathered again under another heading. The platform overview shows the other ten, and coverage lists the regimes they answer.

Related reading: ISO 27001 compliance software and compliance as code in CI.