ISO's common management-system text asks for a controlled procedure in one clause and for proof that it ran in another. Auditors test the second one run at a time, so a 'we do this every month' control depends on what each run leaves behind.
ISO's common management-system text asks for a controlled procedure in one clause and for proof that it ran in another. Auditors test the second one run at a time, so a "we do this every month" control depends on what each run leaves behind.
The common text ISO/IEC 27001 is built on asks for documented information twice, and it means two different things.
That text is the Harmonized Structure, which ISO's Directives publish as the common core of ISO's management-system standards. ISO/IEC 27001 itself is paywalled and adds its own wording on top, so I quote only the common text here.
Clause 7.5.3 covers the documents you write. They must be controlled so that each one "is available and suitable for use, where and when it is needed", and the organization addresses:
- "distribution, access, retrieval and use;- storage and preservation, including preservation of legibility;- control of changes (e.g. version control);- retention and disposition."
That is the life of a procedure: a document with versions, an owner, and a place where people can find it.
Clause 8.1 asks for something else. After requiring criteria for processes and control of the processes "in accordance with the criteria", it says:
"Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned."
"Carried out as planned" describes an event. A procedure cannot show that it was followed, however well it is written and controlled. That needs a second artifact with a date on it, produced each time the procedure runs. The procedure is written once and revised now and then, while run records have to be produced every single time, which is why they tend to be the thinner pile.
The two also age differently. A procedure changes a few times a year and each change replaces the old version. Run records pile up, one per occurrence, and none of them ever replaces another. If both kinds live in the same folder under the same naming scheme, one of them is being handled wrong.
I don't quote SOC 2's attestation guidance here. The freely readable statement of how auditors test controls is the US audit regulator's AS 2201. It governs audits of internal control over financial reporting, a different engagement, but the testing method it describes is the one control testers share.
Paragraph .44 sets the test: whether "the control is operating as designed and whether the person performing the control possesses the necessary authority and competence to perform the control effectively." So the test covers the procedure as it was run, and who ran it.
Paragraph .45 lists the tools: inquiry, observation, "inspection of relevant documentation", and re-performance. Paragraph .50 ranks them from least to most evidence in that order, and adds a note:
"Inquiry alone does not provide sufficient evidence to support a conclusion about the effectiveness of a control."
"We do it every month" is an answer to an inquiry. It is where the test starts. Paragraph .51 says the right test depends on "whether the operation of the control results in documentary evidence of its operation." A monthly server-room walk that leaves nothing behind can be tested only by asking about it or watching it. One that leaves a dated, attributed record can be inspected, run by run, across the period. Paragraph .52 adds: "Testing controls over a greater period of time provides more evidence of the effectiveness of controls than testing over a shorter period of time."
Then there are deviations. Paragraph .48 asks the auditor to judge the effect of any deviation found, and its note is a small mercy: "an individual control does not necessarily have to operate without any deviation to be considered effective." A skipped step with a written reason is a deviation the auditor can weigh; a skipped step nobody wrote down leaves only the gap.
The Commission's Implementing Regulation (EU) 2024/2690 makes the same distinction in its verbs. Under its Article 1 it binds a listed set of digital providers (DNS, cloud, data centers, managed and managed security service providers, marketplaces, and others) directly. For the other NIS2 entities it is the Commission's own concrete version of the Article 21(2) measures.
Annex point 7.1 asks entities to "establish, implement and apply a policy and procedures to assess whether the cybersecurity risk-management measures taken by the relevant entity are effectively implemented and maintained." Establishing a procedure and applying it are separate duties there, in one sentence.
Incident response shows how the split plays out:
ENISA's technical implementation guidance (June 2025, non-binding) lists examples of evidence under each point. Under 3.5.1 the examples are about the procedure being in place: assigned roles, the standards it draws on, and "Playbooks or incident response plans for common types of incidents." Under 3.5.5 the procedure and its runs appear together: "Documented plans or schedules for future incident response tests" and "Records from tests of different types of incidents." The schedule says when a run is owed, and the records show each run took place.
The clause that says the most about deviations is 6.4.3, on change management. The Annex expects a procedure to be skipped now and then, and asks for the evidence of that too:
"In the event that the regular change management procedures could not be followed due to an emergency, the relevant entities shall document the result of the change, and the explanation for why the procedures could not be followed."
ENISA's examples for it include "Logs and records of past change requests" with the reason for the emergency, the approval, the reason for delay, and follow-up actions. The regulation treats a deviation with a written reason as a normal part of the record.
Read together, the three texts give five properties that each run of a recurring procedure should leave on record:
| The run record shows | Why | Where it comes from |
|---|---|---|
| The steps as they stood that day | A run is judged against the procedure in force when it ran. If the procedure has changed since, today's version tells you nothing about March. | HS 7.5.3 control of changes; HS 8.1 "as planned" |
| Who did each step, and when | The test covers the person as well as the procedure. | AS 2201 .44 |
| What was skipped, and why | A deviation with a reason can be assessed. One with no record can't be. | AS 2201 .48; 2024/2690 6.4.3 |
| Which due date it answered | Without a schedule you can't see a missing run, and sampling needs the full list of runs over the period. | AS 2201 .52; ENISA under 3.5.5 |
| That it has not changed since it was filed | Otherwise the record shows only what it says today, and the tester has no way to rely on it. | HS 7.5.3 "loss of integrity" |
None of this needs a particular tool. A paper form with a version number printed in the footer, initials beside each line, a comments box, and a binder sorted by month meets all five. The trouble with paper is the gap between runs: nothing tells you the June form was never filled in until someone counts the binder.
I would drop one habit entirely: attaching the blank template as the evidence for a recurring control. It answers 7.5.3 and says nothing about 8.1.
devguard released Processes in App 2.3.0 on 22 September 2026.
A process is either a checklist someone works through or a report form someone files when something happens. People run them in the employee portal. Each run keeps its own copy of the steps as they stood when it started, so editing the process later changes no submitted run. Each checklist row records who ticked it, when, and an optional note, and a colleague can pick up an open checklist and finish it. Once a checklist is submitted it can no longer be edited, and the owner role is notified with how many rows were ticked. A single run can be linked to an evidence item and through it to controls, or exported as a PDF that lists every row with who checked it and when, taken from the run's own copy of the steps.
Recurring checklists appear in Deadlines. When one comes due or goes overdue, the people who run it are notified, or the owner role if everyone may run it. Report forms can mark fields as required and refuse a report without them. A filed report moves through submitted, being handled and resolved, and editing a resolved one takes an explicit unlock that the run's timeline records.
Three things are deliberately absent, and each has a cost.
First, the app does not version or approve the procedure itself. The version number is a free-text field you maintain, and the steps have no approval workflow. Each run's own copy answers "which steps applied that day". The procedure's own change history and sign-off belong in your policy or records process.
Second, a submitted checklist has no review step. It is complete when submitted. A checklist can also be submitted with rows unticked, and the owner sees the count. If your control needs a second person to review each run, that review is not captured here.
Third, the due date follows the work. The next due date is calculated from when the last run was completed, so one late run does not squeeze every later cycle. The cost is drift: if your control says "in each calendar month", check the dates yourself. An owner or admin can also delete a submission, including its answers and history, so decide who holds those roles.
Before your next audit, pick one control your team describes as "we do it every month" and try to produce its last three runs. For each run you need the steps as written that day, who did each one, and what was skipped and why.
devguard Processes run checklists and report forms in the employee portal and file each run as a dated record; the changelog has the details.
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.