--- id: SOV07 pillar: sovereignty title: SOV 7. How do you produce the evidence an auditor or investigator will ask for? description: Evidence cannot be produced retrospectively. Either the records existed when the event happened, or the answer is that nobody knows, which is a finding. status: draft services: [audit-log, telemetry-router, archiving] tiers: [1, 2, 3] sidebar: order: 16 label: Auditability source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-07-auditability/" source_file: "docs/architecture/pillars/sovereignty/sov-07-auditability.mdx" --- Auditability is a design property rather than a reporting exercise. When somebody asks who changed a permission eight months ago, or which accounts accessed a data set during a specific week, the answer exists or it does not, and no amount of effort afterwards creates it. The distinguishing feature of a system that is auditable is that evidence is a by-product of normal operation. Where producing it is a project, it will be produced late, incompletely, and only when somebody demands it. ## Best practices - [`SOV 7.1`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-71-record-the-actions-an-auditor-or-investigator-will-ask-about) Record the actions an auditor or investigator will ask about - [`SOV 7.2`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-72-protect-records-against-modification-by-the-parties-they-record) Protect records against modification by the parties they record - [`SOV 7.3`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-73-retain-for-the-period-the-obligation-requires) Retain for the period the obligation requires - [`SOV 7.4`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-74-make-evidence-a-by-product-rather-than-a-project) Make evidence a by-product rather than a project --- ## SOV 7.1 Record the actions an auditor or investigator will ask about **Risk if not established:** High Work backwards from the questions rather than forwards from what is easy to log. The questions are predictable and there are not many of them. Who has access to this data, and who granted it. Who accessed it, when, and from where. What changed in the configuration, by whom, and when. Was this control in place during the period under review. When did this incident begin and what happened during it. Each requires a specific record to have existed at the time. Access grants need a change record. Data access needs an access record. Configuration needs a change history. Control state over a period needs either continuous evidence or a dated attestation. Two layers produce these and both are needed. **Platform actions**, meaning who created, modified or deleted infrastructure and permissions. **Application actions**, meaning who read or changed a record inside the workload, which the platform cannot see and which is [`SEC 11.1`](/architecture/pillars/security/sec-11-detection-and-response/#sec-111-collect-security-relevant-signals-where-the-subject-cannot-alter-them). Assessments almost always ask about the second, and it is the one that is missing, because nobody implemented it during the build. **On STACKIT.** The Audit Log records actions on platform resources, is active by default, and can be viewed at organization, folder and project level. Default-on matters here: the records exist for the period before anybody thought to ask, which is the period an assessment is usually interested in. What it does not cover is what happens inside your workload. Access to a row in your database is application behaviour, and the record of it has to be designed in. **Tradeoffs.** **Performance Efficiency** and **Cost Optimization.** Application-level access logging adds work on every read and produces volume that has to be stored, which [`SUS 5`](/architecture/pillars/sustainability/sus-05-data-lifecycle/) and `COST 6` both notice. The mitigation is logging the accesses that matter rather than all of them. **Verify.** Take the question "who accessed this record last March". Can you answer it today? --- ## SOV 7.2 Protect records against modification by the parties they record **Risk if not established:** High An audit record that an administrator can alter answers the question only for people who were not going to lie. That is most people, and it is not the population the record exists for. Three properties matter. **Separation**, so that the ability to perform an action and the ability to alter its record are held by different parties. **Immutability**, so that a written record cannot be changed. **Integrity**, so that alteration would be detectable rather than silent. The strongest practical arrangement is a copy in a separate boundary written by a mechanism the audited party does not control. Separation matters more than sophistication: a plain copy somewhere the subject cannot reach is worth more than a cryptographic scheme in a system they administer. Include deletion in the threat. A record that can be deleted rather than modified has the same problem, which is why retention that cannot be shortened is part of the control rather than a storage setting. **On STACKIT.** Audit records are produced by the platform rather than by your workload, which provides the separation for platform actions: a project administrator performs actions and does not write the record of them. For records you export or produce yourself, Archiving provides immutable retention, which is the mechanism for a copy that persists in a form nobody can quietly amend. Where regulatory retention applies, that immutability is the point rather than a durability feature. **Tradeoffs.** **Operational Excellence.** Immutable records cannot be corrected, which means a mistake in what is written persists. **Cost Optimization.** A second copy in a separate boundary costs storage for the whole retention period. **Verify.** Who in your organization could alter or delete an audit record without leaving a trace? --- ## SOV 7.3 Retain for the period the obligation requires **Risk if not established:** High Retention is where audit records most often fail, because the platform default is an operational period and the obligation is a regulatory one. The two differ by years. Establish the required period from the obligation rather than from what is convenient, and note that different record types frequently have different periods. Then compare it against what the systems currently retain, which is the moment the gap becomes visible. Where the gap exists, export is the answer and it has to be configured before the records age out. Nothing recovers a record that was never exported, and the discovery usually happens when somebody asks for a period that has already expired. Retention that is too long is also a finding, from the other direction. Records containing personal data are subject to the same minimization [`SUS 5`](/architecture/pillars/sustainability/sus-05-data-lifecycle/) and [`SEC 3`](/architecture/pillars/security/sec-03-data-classification/) describe, and keeping everything indefinitely is neither compliant nor cheap. **On STACKIT.** Audit log entries are retained for 90 days, which covers operational investigation and does not cover a multi-year regulatory obligation. That gap is the design point of this practice. Where a longer period is required, records have to be exported to a store you control before they expire, and the Telemetry Router is the mechanism for forwarding them onward. The destination then carries the retention and the immutability requirements from [`SOV 7.2`](/architecture/pillars/sovereignty/sov-07-auditability/#sov-72-protect-records-against-modification-by-the-parties-they-record), which is where Archiving fits. The export needs to be running before the records you will want have aged out, which makes this one of the few practices in the framework with a deadline attached to it. **Tradeoffs.** **Cost Optimization.** Long retention of high-volume records is a continuing cost that grows monotonically, and it is one of the clearest cases where the requirement rather than the architecture sets the bill. **Verify.** What retention period does your obligation require, and what do your systems retain today? Is an export configured, and when did it start? --- ## SOV 7.4 Make evidence a by-product rather than a project **Risk if not established:** Medium Where producing evidence requires a manual effort, it happens once a year under time pressure, it is incomplete, and the gaps found are gaps that existed all along. The alternative is to make the evidence continuously available: records collected automatically, queryable by whoever needs them, and covering the period without intervention. The audit then becomes a retrieval rather than an investigation. The same records serve the incident question in [`SEC 11`](/architecture/pillars/security/sec-11-detection-and-response/), so the work is shared. An investigation and an audit ask the same thing at different times, which is the strongest argument for building it once properly. Test retrieval rather than assuming it. A record that exists and cannot be found within a reasonable time is a record that will not be produced when it is asked for, and the failure mode is discovered during the audit. Where a control's evidence is genuinely manual, such as an approval or a review, capture it as it happens rather than reconstructing it. A dated record written at the time is evidence; one written afterwards is a recollection. **On STACKIT.** The audit log is available through the portal and through an API, which is what makes a query into a scheduled report rather than a manual extraction. Building the queries that answer your recurring assessment questions once, and running them on a cadence, is [`OPS 10.2`](/architecture/pillars/operational-excellence/ops-10-toil-elimination/#ops-102-automate-what-recurs-starting-with-the-riskiest-rather-than-the-most-frequent) applied to compliance. **Tradeoffs.** **Operational Excellence.** Building the retrieval path is work done in advance for a benefit that arrives later, which is the shape of most of this pillar. **Verify.** How long did your last evidence request take to fulfil, and how much of it was manual? --- ## Related - [`SEC 11`](/architecture/pillars/security/sec-11-detection-and-response/) Detection and response, which uses the same records - [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) Compliance mapping, which this supplies the evidence for - [`SOV 3.2`](/architecture/pillars/sovereignty/sov-03-telemetry-residency/#sov-32-establish-where-every-telemetry-destination-actually-is) Telemetry destinations, which the export creates one of - [`SUS 5`](/architecture/pillars/sustainability/sus-05-data-lifecycle/) Data lifecycle, which pulls retention the other way - [`OPS 10.2`](/architecture/pillars/operational-excellence/ops-10-toil-elimination/#ops-102-automate-what-recurs-starting-with-the-riskiest-rather-than-the-most-frequent) Automation, which turns retrieval into a report