Compliance Should Fall Out of Engineering

The Decision in Front of You

Every company that sells to other businesses eventually has to prove its security. The question is how. The common answer is a project for each audit: a consultant, a readiness phase, weeks of engineers taking screenshots, and a binder or shared folder handed to the auditor. Then the next audit starts, with a different framework and often a different team.

The alternative is to treat compliance as an output of the engineering system. Controls are defined once, checked automatically where possible, and their evidence is collected as a by-product of normal work. An audit becomes a report run against data the company already keeps.

The money involved is mostly people's time, and it grows with every framework and every enterprise customer. The risk is larger than the cost. When compliance documents are written separately from the systems they describe, they drift apart, and regulators now treat that gap as misrepresentation.

What's Happening

The frameworks multiply and change

SOC 2 reports are built on the AICPA's Trust Services Criteria, issued in 2017 with revised points of focus in 2022, covering security, availability, processing integrity, confidentiality and privacy ¹. ISO/IEC 27001:2022, the third edition of the international standard for information security management systems, was published on October 25, 2022 ². PCI DSS version 4.x added 64 new requirements; 51 of them were future-dated and became mandatory on March 31, 2025 ³.

Customer questionnaires add another layer. The Cloud Security Alliance's Cloud Controls Matrix, now at version 4.1, contains 197 control objectives in 17 domains and includes a yes-or-no questionnaire, the CAIQ, that many buyers send to cloud providers ⁴. CSA maps the matrix to ISO, NIST and PCI requirements and publishes the mappings in machine-readable formats ⁴.

These frameworks overlap heavily. Access reviews, change approval, logging, backups and vendor oversight appear in nearly all of them under different numbers. NIST runs a program, the National Online Informative References program, to publish standard mappings between its documents and other frameworks for this reason ⁷.

Government is moving to machine-readable evidence

NIST's Open Security Controls Assessment Language, OSCAL, provides formats in XML, JSON and YAML for control catalogs, baselines and security plans, so that they can move out of Word and Excel documents ⁶. NIST describes the goal as shorter audits, fewer human errors and less time spent on documentation ⁶.

The U.S. government's cloud authorization program, FedRAMP, announced FedRAMP 20x in March 2025 ⁵. It replaces document-heavy reviews with Key Security Indicators validated automatically, and FedRAMP says the approach is meant to replace static yearly manual assessments as it matures ⁵. In the first pilot, which ran from April to September 2025, FedRAMP received 26 complete packages and issued the first pilot authorizations in late July 2025 ⁵. The second pilot, at the Moderate level, granted its first authorization on March 6, 2026 ⁵. FedRAMP plans to stop accepting new certifications under its older Rev5 process on June 11, 2027 ⁵.

Continuous evidence has a long history. NIST SP 800-137, published in 2011, set out continuous monitoring as ongoing visibility into assets, threats and the effectiveness of controls ⁸. What has changed is that FedRAMP is now building its authorizations on it ⁵.

Three cases where the paperwork and the systems disagreed

Georgia Tech, 2025. In September 2025 Georgia Tech Research Corporation agreed to pay $875,000 to settle False Claims Act allegations over U.S. Air Force and DARPA contracts ¹⁰. The government alleged that a lab doing sensitive cyber-defense research ran without anti-malware tools until December 2021 and had no system security plan until at least February 2020 ¹⁰. It also alleged that in December 2020 the institution submitted a cybersecurity assessment score of 98 for a campus-wide environment that did not exist ¹⁰. The case began with a suit by two former members of the cybersecurity team, who received $201,250 ¹⁰. No liability was determined ¹⁰. A score that described a fictional environment met the reporting requirement on paper and failed it in fact.

GoDaddy, 2025. In January 2025 the Federal Trade Commission announced an action alleging that GoDaddy had failed since 2018 to inventory its assets, manage software updates, log and monitor security events, and segment its shared hosting ¹¹. The FTC said the company advertised reasonable security and compliance with the Privacy Shield frameworks while attackers reached customer websites and data between 2019 and 2022 ¹¹. The proposed order bars GoDaddy from misrepresenting its compliance with any security program and requires independent assessments every two years ¹¹. Each failure the FTC listed is a control that can be checked automatically.

Delve, 2026. In March 2026 an anonymous whistleblower who said they worked at a former customer accused Delve, a venture-backed compliance automation startup, of producing fabricated evidence of board meetings, tests and processes that never happened, and of routing most clients through two audit firms that rubber-stamped its reports ¹². Delve disputed the claims, said final reports are issued only by independent licensed auditors, and said it provides templates ¹². Its lead investor, Insight Partners, temporarily removed its published article about the investment ¹³. These are allegations, and no regulator had acted on them in the coverage reviewed ¹²¹³. The lesson holds either way: automating the paperwork is different from automating the controls, and a buyer cannot tell the two apart from a report alone.

Why the Usual Approach Fails

Audit-as-project collects evidence at the wrong time. Screenshots taken the week before fieldwork show that a control worked that week. They say nothing about the other fifty-one.

It also collects evidence from the wrong place. A compliance analyst asks an engineer for proof, and the engineer produces something that looks right. The evidence is a description of the system, made by hand, and it can be wrong without anyone intending it. The Georgia Tech allegations turned on exactly this gap between a reported score and real systems ¹⁰.

Separate projects for each framework multiply the work. The same access review is evidenced three times in three formats for three auditors, and then summarized again in answers to customer questionnaires. When the frameworks change, as PCI DSS did in March 2025 ³, each project is reworked on its own.

Finally, nobody is accountable for whether controls work between audits. The compliance team owns the report, and engineering owns the systems. A control can fail for months and surface only at the next audit, or in an incident.

The Framework: One Control Set, Evidence by Default

The model has four parts. The company keeps one control set. Each control is checked by the system where possible. Evidence flows automatically from the systems of record. Each audit and questionnaire is a view of that data.

flowchart LR
    A[One control set<br/>mapped to every<br/>framework] --> B[Controls as code<br/>checks in pipelines<br/>and cloud config]
    B --> C[Evidence collected<br/>from identity, cloud,<br/>CI/CD and tickets]
    C --> D[Exceptions<br/>owner and due date]
    C --> E[Reports<br/>SOC 2, ISO 27001,<br/>PCI DSS, questionnaires]
    D --> B

One control set. Write the company's own controls once, in plain language, each with an owner. Map each to the framework requirements it satisfies. The Cloud Controls Matrix and NIST's published mappings give a starting crosswalk ⁴⁷. A control that satisfies no framework and no internal risk is a candidate for removal.

Controls as code. Where a control is technical, express it as an automated check. Infrastructure is defined in code and checked against policy before it is deployed. Production changes go through a pipeline that records the approval and the test result. Encryption, logging and network segmentation are verified by scheduled checks against the live cloud configuration. These are the failures the FTC described at GoDaddy ¹¹.

Evidence by default. The identity provider already records who has access and when it was reviewed. The deployment pipeline records every change and its approver. The ticketing system records incidents and their resolution. Collect evidence from these systems on a schedule and store it with a timestamp. Use OSCAL or a similar structured format so that the evidence can be shared with auditors and customers without rework ⁶.

Exceptions with owners. A failing check opens an exception with an owner and a due date. The exception count by age is the measure leadership watches.

What it saves: an illustration

The following is the author's illustrative estimate for a hypothetical software company with SOC 2, ISO/IEC 27001 and PCI DSS obligations and 150 customer security questionnaires a year. Assumptions: manual preparation takes 600 hours for SOC 2, 400 for ISO 27001 and 500 for PCI DSS, and each questionnaire takes 8 hours, for 2,700 hours a year. With one control set and automated evidence, each audit takes 150 hours of support, each questionnaire 1.5 hours drawn from a maintained answer library, and the system needs 300 hours a year of upkeep, for 975 hours. The build costs an assumed 1,200 hours in the first year.

On those assumptions the first year costs 2,175 hours, 525 fewer than the manual approach. Every following year saves 1,725 hours. The larger return is outside the arithmetic: a control that fails in March is found in March.

Costs, Risks, and Tradeoffs

How to Act

Questions to Ask Your Team

1. How many frameworks, audits and questionnaires did we answer last year, and how many hours did each take?
2. Do we have one list of controls, or one per framework?
3. For our ten most important controls, where does the evidence come from, a system or a person?
4. If a control failed today, how long before we would know?
5. Does every public statement we make about security match what our systems would show an investigator?
6. Could an auditor read our evidence directly, or does someone assemble it first?
7. If we use a compliance platform, can we trace each piece of its evidence to a live system?

Closing

Running each audit as a separate manual project pays for the same evidence several times and produces documents that drift from the systems they describe. Regulators now penalize that drift, and the federal government is moving its own authorizations to continuous, machine-readable evidence. Keep one control set, check it in code, collect evidence from the systems that run the business, and let each audit and questionnaire be a report on that data.