Research program
GRC engineering
Governance, risk, and compliance teams write policies, maintain spreadsheets, collect screenshots, and answer questionnaires. This program asks how much of that evidence the systems themselves can produce.
Which parts of governance can be converted from document production into continuous evidence?
The conversion
Claim: hypothesis
Much of the work in GRC turns system data into reports on a schedule. Machines can do more of that without weakening oversight.
People still have to decide which risks to accept, which exceptions are reasonable, what the evidence means, and when to stop an activity. Report preparation often leaves too little time for those decisions.
Where the engineering sits
Claim: recommendation
Software engineering already has useful ways to handle each layer. Security and compliance teams can use them too.
| Governance artifact | Engineering equivalent | What it produces |
|---|---|---|
| Written policy | Machine-readable policy with an enforced rule | A statement that can be tested, versioned, and diffed |
| Control narrative | Controls as code with an executable test | A pass, fail, or unknown result on a schedule |
| Evidence screenshot | Evidence pipeline with query provenance | An artifact an auditor can reproduce |
| Annual control review | Continuous test with drift alerting | Time between drift and detection as a metric |
| Risk register | Linked findings with measured blast radius | Prioritisation based on reach rather than severity labels |
| Audit preparation | Standing evidence store | An audit that reads rather than assembles |
Related work at the firm
Claim: observation
This program connects to existing research on AI-native software, observability, and evidence-bearing operations. Work on Operational Truth supplies the state distinctions used throughout, and work on unbundling knowledge work supplies the method for deciding which governance tasks should be human, machine, shared, redesigned, or removed.
These links provide research context. They do not claim that a product solves the problem.
What would prove us wrong?
Claim: unknown
The program assumes automated evidence production improves governance rather than merely accelerating it.
- Evidence that automated evidence volume reduces the attention paid to each item, producing worse decisions than a smaller manual set.
- Auditor behaviour showing that machine-collected evidence is discounted or re-requested in human form, adding cost rather than removing it.
- Cases where the effort to encode controls exceeded the recurring effort it replaced, for environments below a certain size.
Experiments for this program
- Map every requirement to an operational data source How many requirements can be answered by a machine today?
- Consent enforcement probe Does a withheld consent change what downstream systems do?
- How long does drift survive? When a control is quietly disabled, how long before anyone notices?
Patterns and anti-patterns
- Store the query, not the screenshot (pattern)
- Writing a narrative where no data source exists (anti-pattern)
Evidence for this program
- NIST SP 800-53 revision 5, security and privacy controls A large control catalogue, useful for mapping requirements to testable statements.
- NIST Privacy Framework A structure for privacy outcomes that can be mapped to engineered tests.
- Compliant Insecurity Collected material on organisations that satisfy their frameworks while remaining unable to detect, contain, or recover.
- Operational Truth The intended, reported, recorded, inferred, observed, and verified distinction used throughout this area.
Research notes
Governance runs short of time for judgment
The note's claim, a hypothesis, is that judgment is the scarce part of governance, risk and compliance work, because evidence collection takes the hours that decisions need. When collecting and formatting evidence takes most GRC hours, little time remains for decisions. Automating the clerical work may give that time back.
Generate the policy from the enforced rule
Where a platform enforces a setting, produce the written policy from that configuration. Then the rule and the document cannot drift apart. Keep the enforced rule as the source of record, mark policy without enforcement as unenforced, and report how many policy statements are actually enforced.