One obligation fixes a number of years, the other fixes no interval at all — here are the clauses that impose each, and the fields that fall out of them for any evidence record.
Of the two duties a regulator attaches to a piece of compliance evidence, the one with a number in it is the easier one, and it is the one evidence stores get built around. Regulation (EU) 2024/2847, the Cyber Resilience Act, carries both. Art. 13(13) requires manufacturers to keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities "for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer." Art. 31(2) then requires the same documentation to be "continuously updated, where appropriate, at least during the support period", which is a recurring act with no interval attached to it. A store that gives each record one date answers the first article and looks like it answered the second.
Read across instruments, the duty is demonstrability: producing a particular proof, to a named party, at a moment you do not choose.
The CRA settles the first two and adds a duration. Art. 13(13) names the duty-holder (manufacturers), the object (technical documentation and the EU declaration of conformity), the audience (market surveillance authorities) and how long the obligation runs. Art. 31(1) and Annex VII say what sits inside that object: the software bill of materials, the coordinated vulnerability disclosure policy, test reports, a copy of the declaration itself. What the CRA does not settle is the timing, and that comes from the supervisor's side.
GDPR states the demonstrability duty directly and attaches no period to it anywhere. Art. 5(2): "The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability')." Art. 24(1) requires the controller to implement measures "to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation", and closes:
"Those measures shall be reviewed and updated where necessary."
That sentence fixes no interval and names nothing that starts the clock. Art. 30(4) supplies the on-demand half: the record of processing activities is made "available to the supervisory authority on request". Art. 30(5) carves out organisations employing fewer than 250 persons unless one of its listed conditions applies, so that duty is not universal.
NIS2 puts the same demand in the supervisor's hands. Art. 32(2) requires Member States to ensure competent authorities can subject essential entities "at least to" seven measures, the last of which, point (g), is:
"requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence."
The same power appears for important entities at Art. 33(2), point (f), inside the ex-post regime Art. 33(1) sets up. Two details in that wording earn their place in a data model. It asks for the audit result and the material sitting under it. And Art. 32(3) bounds the request: authorities exercising points (e), (f) or (g) "shall state the purpose of the request and specify the information requested". What arrives is a scoped question about a particular thing, on a date nobody at the receiving end picked.
NIS2 has no counterpart to GDPR Art. 24(1), and it is easy to assume one: Art. 21(1) and (2) contain no review-and-update sentence, and I went looking for it. The pressure NIS2 puts on currency is supervisory instead: an authority may ask on any day, so the proof has to be adequate on any day.
The wording quoted as "the ISO 27001 documented-information clause" is not original to ISO/IEC 27001. It derives from the Harmonized Structure that the ISO/IEC Directives, Part 1, Consolidated ISO Supplement requires management-system standards to apply. Annex SL, clause SL.8.2: "Type A MSS shall apply the harmonized structure detailed in Appendix 2." Type A is defined in the same annex as an MSS "providing requirements", which is what ISO/IEC 27001 and ISO 22301 both are — each prints a title ending in "— Requirements".
"Derives from" is as far as I will take it. The Directives permit a committee to "add or insert discipline-specific text" (SL.8.3(e)) and, in exceptional discipline-specific circumstances, to "amend the text and introduce a deviation" (SL.8.3(i)). The free Harmonized Structure document, Appendix 2 to Annex SL and reachable from that supplement page, was approved on 2025-07-30 under TMB Resolution 74/2025. It carries a change-log entry recording the "[a]ddition of a full stop at the end of Annex SL clause 7.5.3". A revision log still tracking punctuation inside 7.5.3 in 2025 rules out any claim of textual identity with a standard whose current edition dates from 2022. That catalogue entry is where the edition year comes from; the standard itself is paywalled, I did not open it, and nothing quoted here comes from it.
The free text does show the skeleton already splitting the two obligations. Clause 7.5.2, "Creating and updating documented information", requires the organization to ensure appropriate:
- identification and description (e.g. a title, date, author, or reference number);- format (e.g. language, software version, graphics) and media (e.g. paper, electronic);- review and approval for suitability and adequacy.
Clause 7.5.3, "Control of documented information", requires that documented information "shall be controlled to ensure ... it is available and suitable for use, where and when it is needed", and lists the activities the organization shall address "as applicable": distribution, access, retrieval and use; storage and preservation; control of changes; "retention and disposition".
The currency duty sits in 7.5.2 and the retention duty in 7.5.3, one sub-clause apart, inside the skeleton that every requirements standard is bound to apply. Neither of them carries a period.
One count is worth publishing, with its labelling attached. Over the normative text of that Harmonized Structure document, the word "retain" appears zero times. The recurring formula is "Documented information shall be available as evidence of …", five occurrences, in clauses 7.2, 9.1, 9.2.2, 9.3.3 and 10.2, covering competence, monitoring results, the internal audit programme, management review results and corrective action. That count is over the Harmonized Structure, not over ISO/IEC 27001. "Available" is the operative verb, and it is the same demand the regulations make: retrievable at the moment somebody asks.
| Obligation | Clause | What it constrains | What breaks if you track only the other one |
|---|---|---|---|
| Retention | CRA Art. 13(13) | How long documentation stays at the disposal of market surveillance authorities: at least 10 years, or the support period | The record is disposed of while the duty is still running, and there is nothing left to produce |
| Currency (document) | CRA Art. 31(2) | That documentation is "continuously updated, where appropriate, at least during the support period" | The file is validly retained and no longer describes the product it documents |
| Currency (process) | GDPR Art. 24(1) | That measures are "reviewed and updated where necessary" — a recurring act with no interval | Last year's proof is on file and nothing records that a fresh look is due |
| Availability | GDPR Art. 30(4); NIS2 Art. 32(2)(g) | That a named authority can be handed the record, and the evidence underneath it, on request | A current, well-retained record that nobody can locate against a scoped request |
The two clocks have different owners. That is the practical reason one field cannot serve both. A document's validity window is set by whoever issued it: a certification body, a pentest firm, a counterparty who signed a DPA. The organisation holding the document inherits that date and cannot move it. A review cadence is the organisation's own decision, and someone inside the organisation has to be answerable for it.
The collisions are ordinary: a certificate lapses three months into a twelve-month review cycle, so the calendar says fine while the artifact is dead; or a review falls due on a document that is still valid, because what is being asked is whether the claim holds, not whether the PDF has expired.
Retention also has a defined end that currency does not. Harmonized Structure 7.5.3 pairs retention with disposition, and CRA Art. 13(13) runs out. A currency duty runs until the underlying obligation lapses, which is why it never presents itself as a countdown.
Five fields, in any tool, including a spreadsheet:
| Field | Question it answers | Obligation it serves | Who sets it |
|---|---|---|---|
| Owner | Who is answerable for this proof existing and being findable | Availability (GDPR Art. 30(4), NIS2 Art. 32(2)(g)) | The organisation |
| Approver, plus the timestamp of the approval | Who last judged this adequate, and when | Currency (HS 7.5.2, "review and approval for suitability and adequacy") | The organisation |
| Validity window on the document (issued, expires) | Is this artifact still inside the period its issuer vouched for | Currency, at document level (CRA Art. 31(2)) | The issuer |
| Review cadence and next review date on the item | When does somebody have to look at this again | Currency, at claim level (GDPR Art. 24(1)) | The organisation |
| Link to the control or requirement it supports | What this is proof of, and what it can be produced against | Availability | The organisation |
The non-obvious pairing is the third against the fourth. An expiry date belongs to the document, because one evidence item can hold several documents with different expiries: a certificate, the report behind it, an attestation letter. Put a single expiry on the item and you are storing either the earliest one, which is wrong for every other attachment, or a copy that drifts from its source. A review date belongs to the item, because "is this still adequate?" is a question about the claim, not about one attachment. Retention and disposition then hang off whichever of the two the applicable duty binds.
Capturing all of this while the work happens, rather than the week before an audit, is a separate argument; Angelo made it in the case for treating readiness as a state you keep.
devguard's evidence schema is one worked example of that shape. The two dates sit on two different models:
// packages/app-db/prisma/schema.prisma (other fields elided)model Evidence { reviewFrequency EvidenceReviewFrequency? lastReviewedAt DateTime? nextReviewAt DateTime?}model EvidenceFile { documentKind EvidenceDocumentKind? issuedAt DateTime? expiresAt DateTime?}
nextReviewAt is computed rather than typed in: computeNextReviewAt in apps/app/api/evidence/next-review.ts maps MONTHLY, QUARTERLY, SEMI_ANNUAL and ANNUAL to addMonths(from, 1 | 3 | 6 | 12). CONTINUOUS maps to null: an item verified continuously has no next review date, because the question does not apply to it.
Approval is the review. One mutation stamps approvedAt and approvedBy and re-anchors lastReviewedAt and nextReviewAt in the same write, and the comment above it says why: "Approval is the single sign-off event (there is no separate 'mark reviewed')". There is no second timestamp to drift from the first.
NIST SP 800-53A Rev. 5 is a US federal assessment methodology, and I am using it here as an account of what assessment is, not as a framework anyone reading this has to adopt. Section 2.4.1 classes assessment objects as "specifications, mechanisms, activities, and individuals", and defines the first: "Specifications are the document-based artifacts (e.g., policies, procedures, plans, system security and privacy requirements, functional specifications, architectural designs)". A document is a thing being assessed. Three of the four object types cannot be held in a document store at all.
The methods act on those objects. Examine is "the process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects". The output is a finding, produced by a person: each determination statement "executed by an assessor" yields satisfied or other than satisfied, and other than satisfied "may also indicate that the assessor was unable to obtain sufficient information to make the determination". An artifact can be present, correctly filed, still in date, and the determination can fail to land.
A data model that treats link creation as a determination is therefore recording a conclusion nobody reached. What a link can honestly record is that something relevant exists and has not been resolved.
devguard derives a control's coverage status at read time, in a fixed precedence:
// apps/app/api/coverage/derive-coverage-status.ts — body of// deriveControlCoverageStatus(), whose docstring gives the precedence as// "not-relevant → tasks → evidence-links → UNKNOWN"if (signals.isNotRelevant) return 'NOT_RELEVANT';const tasks = signals.taskStatuses.filter(s => s !== 'CANCELLED');if (tasks.length > 0) { if (tasks.every(s => s === 'DONE')) return 'FULL'; if ( tasks.some(s => s === 'DONE' || s === 'IN_REVIEW' || s === 'IN_PROGRESS') ) return 'PARTIAL'; return 'NONE';}if (signals.hasEvidenceLinks) return 'PARTIAL';return 'UNKNOWN';
Read it as a ceiling. Linking evidence to a control that carries no tasks moves it from UNKNOWN to PARTIAL, and PARTIAL counts as covered in the aggregate percentage, so attaching a file does move the number before anyone has judged whether the file shows the control operating. That is the honest cost of this design. What evidence alone can never produce is FULL: that branch requires tasks, and every one of them DONE. Where tasks exist they decide the status outright, and the evidence branch is never reached.
There is no automated evidence collection in devguard. The evidence system's design spec puts the runtime out of scope in those words ("Any automated evidence-collection runtime — check execution, result→coverage reconcilers, scheduler/worker runs, connector DSLs") and describes what shipped instead as "a display-only association" where "nothing runs". The code agrees. setAutomation in apps/app/api/evidence/index.ts writes a single column:
return ctx.db.evidence.update({ where: { id: input.id }, data: { automationActionId: input.automationActionId },});
The evidence list has a column headed "Collection"; it renders the linked action's name, or "Manual" when there is no link. Integration connectors exist elsewhere in the codebase, in packages/app-workers/src/integrations/, and none of them reads or writes evidence. Nothing fetches the artifact; someone attaches it and someone approves it.
[screenshot: evidence detail, review cadence panel]
Whatever you already run (a spreadsheet, a wiki page, a folder of dated subfolders), the change that pays for itself is two date columns instead of one: an expiry that belongs to the document and arrived with it from whoever issued it, and a next-review date that belongs to the claim and is yours to set. Put a role name against the second column, because the first arrives with an owner attached and the second does not. Then "what expires next?" and "what needs looking at next?" stop returning the same list, which is the first sign the two obligations are being tracked separately.
The evidence model this post describes is documented at docs.devguard.ch/evidence.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.