Compliance and evidence
Which frameworks, what evidence, and where the data lives.
Written for the CISO and the compliance lead who will have to defend the choice internally. It covers the frameworks StaidKit is being built to serve, what an audit packet contains, the residency model, and how agent decisions are governed.
It also covers what StaidKit is not, which is certified. That section is first.
Our own posture
StaidKit is not certified.
There is no SOC 2 report for StaidKit, no ISO 27001 certificate, and no HIPAA attestation. No assessor has examined this company. If you need a vendor whose trust page goes into your third-party risk file today, that is not us yet.
The first SOC 2 Type II audit period is scheduled ahead of general availability, and completing it is a stated condition of shipping: the frameworks StaidKit is built to serve have to apply to StaidKit. Until that report exists there is nothing to send you, and we will not imply there is.
Spec §13, §16
Everything else on this page is the other side of the relationship: the evidence StaidKit is designed to produce for your frameworks, in your audit, about your operations.
Those are separate questions and they are answered by separate things. A vendor certification tells you a third party examined our controls once a year. An evidence pipeline tells you that your assessor can trace a change in your production estate back to the decision that caused it. You need both, and they do not substitute for each other.
The premise
Evidence as a by-product of operating, not a project that starts eight weeks out.
Audit preparation is usually a reconstruction: screenshots, exports, and chasing people for approvals that were given in a chat thread nobody kept. That happens because the operational system was never asked to hold the record in the first place.
The design inverts that. Running an incident writes the record as it happens: the state transition, the agent recommendation with the inputs behind it, the approval and who gave it, the executed action and its outcome. Preparing for an audit becomes a query over a range of that record rather than an attempt to rebuild it from memory. Spec §6.5
Which parts of that are real today matters more than the idea. The services that produce the operational record are running. The models that hold controls and evidence exist. The hash chain that makes the record verifiable, and the packet builder that reads a range out of it, are not built. That is the honest shape of it.
The operational record
ImplementedIncidents, telemetry intake, assets, on-call, and the Datadog and ServiceNow integrations that feed them.
Controls and evidence
PartialControl, evidence and assessment models with an API, plus a collection scheduler. No framework catalogue is loaded.
The ledger and the packet
SpecifiedThe hash-chained record every claim below depends on, and the export built from a range of it.
Frameworks
What the first release targets, and what comes later.
SOC 2 Type II, ISO 27001 and HIPAA in the first release. DORA follows it. The rest are deferred, and naming them as deferred is more useful to you than a longer list would be.
Decision D8, Spec Appendix B
| Framework | Designed to produce | Release | Status |
|---|---|---|---|
SOC 2 Type II | Action-level evidence for the CC-series controls covering monitoring, incident response and change: the incident record, the recommendation, the approval, the executed action, and the artifact filed against the control. | First release | Partial |
ISO 27001 | Annex A evidence for incident management and operational control, mapped from the same records. The statement of applicability and the ISMS scope stay yours. | First release | Partial |
HIPAA | Security Rule evidence drawn from operational records, and the timestamped trail behind breach notification timelines. In the first release because half the target segment operates under it. | First release | Partial |
DORA | ICT incident records held against the reporting clocks (4 hours initial, 24 hours intermediate, one month final), and the third-party risk trail. | Follows the first release | Specified |
NIS2 | Deferred. Member-state specific transposition, with heavy operational overlap with DORA. Serving DORA properly is the prerequisite. | Later | Specified |
SOX | Deferred. ITGC scope, auditor-driven, public companies only. | Later | Specified |
PCI-DSS | Deferred. Requires deployment patterns, a cardholder data environment and segmentation, that StaidKit does not commit to yet. | Later | Specified |
ISO 22301 | Deferred. Business continuity management. | Later | Specified |
What Partial covers, precisely. The compliance service holds the framework types, the control, evidence, assessment and finding models, the API over them, and a scheduler for recurring collection. No framework control catalogue is loaded, so the SOC 2 and ISO 27001 control libraries are still to be written. The evidence collectors for Datadog and ServiceNow issue real API calls; the cloud collectors return fixtures rather than reading an account.
Nothing in that pipeline writes to a ledger, because the ledger is not built. Until it is, collected evidence is a stored artifact with a checksum, not a link in a chain anyone can verify.
Verified against api/compliance-service on this branch
Audit packet
What an audit packet is, exactly.
One framework, one period, one file. The design is specific about the contents because vagueness here is how a compliance claim quietly becomes unfalsifiable.
- The ledger range
- The full chain segment for that tenant over that period, entries in sequence with their previous hashes intact.
- The referenced entities
- The incidents, actions, agent decisions and approvals the entries point at, as they stood when each entry was written.
- The control mappings
- Which control each artifact was filed under, and the state of that control in the period.
- The anchor records
- The external anchors for the range, so the chain can be checked against something StaidKit does not control.
Two properties carry the weight. The export is reproducible byte for byte from the same ledger range, so the packet you send in March and the packet a colleague regenerates in July are the same file, or something is wrong and you can see it.
And the verifier runs independently of StaidKit. Your assessor checks the chain and the anchors on their own machine, against records they hold, without asking us for anything and without taking our word for any of it. An export nobody can check without the vendor is not evidence, it is a report.
Evidence trail
One control, followed end to end.
SOC 2 CC7.4 asks whether you respond to identified security incidents. Here is the chain the design produces for a single incident, and what each link writes.
01
A P1 is declared on checkout-api. A commander is assigned by policy, and the affected services are resolved from the dependency graph.
state_transition · incident_id · severity · affected_service_ids[]
02
The remediation agent proposes a runbook invocation: roll back the last deploy, with its blast radius computed from the graph.
agent_decision · model_id · model_version · prompt_hash · retrieval_set_id · confidence
03
The on-call SRE approves it, because the blast-radius class for this action requires a human approver.
approval · approver_user_id · policy_ref · blast_radius_at_dispatch
04
The action executes and reports its outcome, with the rollback path recorded whether or not it was used.
action · runbook_id · runbook_version · inputs_hash · outputs_hash · outcome
05
The action and the post-incident review are filed as evidence under the control, immutably. A correction creates a new version rather than editing this one.
evidence · payload_hash · control_ref SOC 2 CC7.4 · control_ref ISO 27001 A.16.1.5
An assessor starts at the artifact and walks backwards: evidence to action, action to approval, approval to the agent decision, decision to the incident that prompted it. Each hop is an entry whose hash is computed over the previous one, so the walk either verifies or stops at the exact entry that does not.
This is a worked example of the design, not a screenshot of customer data. The entry shapes come from the domain model, the sequence from the incident narrative in the specification. None of it runs today, because the ledger it hangs from is not built. Spec §5.5, §5.7, §5.8, §6.3
Data residency
Where the data lives.
Two regions at the first release: us-east-1 and eu-west-1. A tenant is pinned to one at provisioning and its records stay in it. Ledger anchors are held per region.
EU residency is in the first release rather than added later, because a large part of the buyers this is built for cannot sign without it, and residency retrofitted onto a single-region system is a migration rather than a setting.
APAC is deferred. If you need it, say so early and it becomes a commercial conversation rather than a roadmap promise.
Cross-region failover targets an RPO under 5 minutes and an RTO under 30 minutes. Target, Spec §11.3
This is the deployment design, and it is worth being blunt about what that means. There is no production deployment serving customers. No tenant is pinned anywhere today, no anchor has ever been written, and none of these boundaries has been tested by anyone but us.
A design partner gets to interrogate the design before it is poured, which is the only point in the life of a system when residency is cheap to change.
Model governance
The AI question your risk committee cannot answer with a toggle.
A vendor AI feature usually cannot tell you which model version produced a given output, what it retrieved to produce it, or who approved acting on it. If the terms also permit training on your operational data, the review ends at the first question and never reaches the second.
Per-tenant boundary at the storage layer
SpecifiedNot at the application layer. Cross-tenant query is meant to be impossible by construction, rather than prevented by a filter someone can forget to apply.
Spec §8.5
No cross-tenant training
SpecifiedNo tenant's operations improve a model another tenant uses. If cross-tenant intelligence is built later, it is federated aggregation, never reading across the boundary.
Spec §8.5, §1 M4
Every decision recorded with its inputs
SpecifiedModel and version, prompt hash, the retrieval set the answer was drawn from, the confidence, the recommended action, and the person who approved it or declined.
Spec §5.7
Agents propose, people approve
SpecifiedAutonomous execution is not in the first release. Approval-gated action is the only posture a regulated operator can defend today, so it is the default rather than a setting.
Decision D9
The shape of this comes from the EU AI Act, which sets record-keeping expectations for high-risk systems in Article 12. An agent that can recommend changes to a production estate is a plausible candidate for that classification, and designing as if it is costs little if it turns out not to be. Spec §1 M2, Decision D9
StaidKit does not claim compliance with the AI Act. Nobody can claim that for a product that has not shipped, and there is no agent code in the repository yet. The claim is narrower: the record the Act asks a high-risk system to keep is the same record this design has to keep anyway to be worth buying.
Your assessor
What you could hand an assessor, and when.
One framework, one period, one file: the control list with the state of each, the artifacts filed under each, the actions and agent decisions that produced them, the approvals with names against them, and the chain segment plus anchors your assessor verifies on their own machine.
That is what a customer could hand over once this is built. It is a specific enough promise that you will be able to tell whether we delivered it.
Today you could hand them none of it. The control and evidence models exist, the operational services that would feed them are running, and the ledger those artifacts hang from is a design document. StaidKit itself holds no certification.
The distance between those two paragraphs is what the first release has to close. It is also the thing worth asking us hard questions about, which is what the design partner programme is for.
Design partner programme
The first release is shaped around what you actually have to prove.
Five partners, chosen so the control coverage is driven by real audits rather than a framework list. If your compliance lead assembles evidence by hand today, that process is the thing we want to watch.