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 is one worked example of that shape, and it splits the two dates along the same seam. The expiry belongs to the attachment: every file on an evidence item carries its own issue date and its own expiry, so a certificate and the report behind it can lapse on different days without one overwriting the other. The review belongs to the item: an evidence item carries a review schedule, the date it was last reviewed and the date the next review falls due, and that next date is derived from the schedule rather than typed in, so it cannot quietly disagree with the cadence somebody chose. An item that an integration genuinely keeps current can instead be marked so that no periodic review is owed at all, which is a different statement from a cadence of zero, and it is why such an item carries no next review date.
Approval is the review. Signing an evidence item off records who approved it and when, and re-anchors the last-reviewed and next-review dates in the same act. There is no separate "mark reviewed", and so 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 reads a control's coverage off what is attached to it, in a fixed order. A control marked not relevant reports that and stops there. Otherwise its tasks decide: every task done reads as fully covered, some of them started reads as partial, none of them started reads as uncovered. Only a control carrying no tasks at all falls through to its evidence, and an evidence link on its own reads as partial.
Read that last step 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 coverage: that reading requires tasks, and every one of them done. Where tasks exist they decide the status outright, and the evidence is never reached.
Evidence collection in devguard is automated now, in one specific shape, and the shape matters more than the word. You declare collectors in a configuration file, each one a command that already runs somewhere in your pipeline: a dependency audit, a scanner report, the output of a plan. The devguard CLI runs them, checks every artifact against a secret pattern set before anything leaves your machine, and pushes the output into a named evidence record. Files that arrive that way are badged as automated in the app, with the collector's name beside the badge, so nobody has to reconstruct later whether a person put the file there.
Each push replaces that collector's previous file. An evidence record holds exactly one current artifact per collector, and files uploaded by hand or produced by a different collector are left alone. The replacement is permanent: the previous artifact is removed rather than archived, so there is no version history behind a collector, and renaming a collector starts a fresh series while the old file sits there with nothing left to refresh it.
Every pushed file carries a freshness window, set per collector. When the window lapses without a refresh, the file is flagged on the deadlines view under Automated Evidence, in the same list as an overdue review. A pipeline that stopped running shows up as a lapsed file rather than as silence, which is the failure mode worth designing for.
Now hold that against the two clocks. Automation is good at exactly one of them, currency at document level. The artifact is regenerated, its issue date moves with it, the freshness window resets, and a stale one announces itself on a page somebody already looks at. That is the CRA Art. 31(2) shape of the duty, and for anything a command can produce it is genuinely handled.
The rest it does not touch, deliberately. A push does not change a control's coverage and does not reset the item's review date. The GDPR Art. 24(1) question, is this measure still adequate, is a judgment about a claim, and a fresh file is an input to that judgment rather than the judgment itself. Retention is not helped either, and in one respect runs the other way: because each push removes the collector's previous artifact for good, a collector is the wrong place to hold something a ten-year retention duty binds. Availability still depends on somebody having linked the record to the control or requirement it answers.
There is a weaker thing in the product with a similar name, and it is worth separating from this. An evidence item can be labelled with the integration action its proof is expected to come from, and the list then shows that name in place of "Manual". That is a label recording where the proof should originate, not a job that fetches it; someone still attaches the file.
So automation buys the document currency clock, and buys it well. The retention clock, the review clock and the link to what the proof is proof of stay exactly where they were, with a person's name against each.
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.