The previous lesson closed by pointing at what kept coming up as the GDPR was applied: the RoPA, contracts, the breach register, restore reports, documents dated before the incident. The Regulation calls that accountability, NIS2 calls it assessment of effectiveness, ISO 27001 calls it documented information and the customer calls it "send me the report". They are all asking for the same thing: being secure is not enough, you have to be able to demonstrate it. This lesson builds the system that makes that possible without costing three days of panic every time: what makes a piece of evidence valid, how it collects itself, how the traceability matrix we have been carrying since 04-03 is completed, how a real auditor behaves and what they ask when they request a sample, and how you respond to a finding without arguing or exaggerating.

1. Being secure and being able to prove it are different things
2. What evidence is and what makes it valid
3. The traceability matrix, in its final form
4. Automating evidence collection
5. Types of audit: who does it and what is at stake
6. The audit process, step by step
7. How an auditor behaves and what they really ask
8. Findings and the corrective action plan
9. Internal auditing in a 38-person company
10. Technical audit versus management audit
11. Customer questionnaires as a de facto audit
12. Compliance metrics and the two traps

Two organisations can have exactly the same real level of protection and get opposite results in front of a customer, an auditor or the AEPD. The difference is not security: it is the trail.

Out of that table come the two statements that structure the lesson, and both must be held at once because each corrects the other's excess. Compliance without security is theatre: an ISO 27001 certificate over controls nobody verifies prevented none of the breaches in 02-06, and Equifax had a compliance programme with the patch unapplied. Security without evidence does not survive: not an audit, not a customer questionnaire, not a change of personnel, not an enforcement file where the weighing expressly values diligence; and it does not survive itself either, because with no record nobody knows whether the control still works, which is the thesis of 06-01. There is also a cost argument that usually convinces anyone who sees compliance as bureaucracy: evidence is cheaper if it is generated while doing the work than if it is reconstructed afterwards. Saving the output of the restore test costs zero minutes on the day the test is run, and costs half a day three months later, when you have to remember who did it, search the chat and write an after-the-fact report that is also worth less because it is not contemporaneous. Auditing is not expensive: reconstructing is expensive.

Evidence is any record that lets a reasonable third party conclude that a control exists and works: it is not an assertion, it is not a stray screenshot and it is not "we always do it". Five attributes, and if two are missing it is no longer evidence:

Types of evidence and examples drawn from the whole course, fulfilling the promise made in 05-07: module 5 did not merely improve Nimbus's security, it kept generating exactly the material now needed.

Two criteria for choosing well. Always prefer evidence the machine generates on its own — an export, a log, a scanner's output — over evidence a person writes: the former is reproducible and hard to dress up. And the one that separates the good from the mediocre: the most valuable evidence is the evidence that shows the control detected something and it was corrected. A flawless restore report quarter after quarter looks suspicious; one that says "it worked, but it did not recreate the roles nimbus_api and nimbus_reports, corrected on 25/06 and re-verified" proves the test was real.

In 04-03 we sketched it as a control-management tool; here it reaches its definitive form, with the two columns that were missing — evidence and frequency — and with the mapping to requirements from 06-02. It is a single document that answers five questions: which risk am I covering, which rule requires it, what do I do, how do I prove it and who answers for it.

And its version as data, which allows reports to be generated, expiries to be spotted and the dashboard to be fed with no manual work:

Why keeping it up to date is cheaper than reconstructing it, with a sum Marta can take into a meeting: maintaining it costs around 10 minutes per control per quarter — note the date, link the evidence, close the finding — some 15 hours a year for 22 controls; reconstructing it for an audit or an urgent customer costs 40-60 hours of Marta's and Lucía's time over three days, with incomplete material because some evidence no longer exists: the log rotated, the chat was purged, the person left. And what is reconstructed afterwards is worth less to an auditor precisely because it is not contemporaneous. The up-to-date matrix costs a third and is worth twice as much. One implementation detail changes the outcome: it lives in the repository, not in a spreadsheet on somebody's desktop, with version control, pull request review and a weekly script that flags the controls whose last verification has passed its frequency_days.

The rule that makes everything above sustainable: if a piece of evidence has to be remembered, it will not be generated. A good part of it can be extracted on its own:

The boundary is sharp and worth respecting: you automate what is a verifiable fact; you do not automate what is a judgement or a decision. Pretending otherwise produces script-generated minutes that no auditor accepts and that, worse, mean nobody reviews anything. A collector that seals what it gathers:

Three design decisions make this count as evidence rather than a heap of files. The hash manifest gives integrity: anyone can check that the file has not changed. The signature gives non-repudiable attribution, using the same infrastructure as 03-06 and 05-07. And immutable storage with Object Lock stops anybody — an attacker erasing traces, or somebody in a hurry before an audit — from altering the history. Notice too that the script ends by saying what it cannot do: it is the best way of making sure the human part is not forgotten. The effect on the audit is what matters: when the auditor asks for "the evidence for the encryption control over the last twelve months", the answer is not a three-day search, it is a directory with twelve dated, signed and verifiable folders.

Three management observations that save grief. The self-assessment has the highest return and is the one almost nobody does: finding a gap yourself costs the fix; having an auditor find it costs the fix and explaining why you did not know. The customer audit is the most frequent and the worst prepared for: it arrives with two weeks' notice, it is carried out by somebody who does not know your architecture and the renewal is at stake, so you prepare for it beforehand, with the pack from section 11. And the regulatory audit is not prepared for: you arrive prepared, because when the AEPD writes the margin is days and only what already existed and was dated counts.

Two points decide the outcome. The scope (step 1) is the most important decision and the least discussed: it defines what is audited and, above all, what is left out. Too narrow and the report is useless to the customer who asked for it; too broad and it drives up the cost and guarantees irrelevant findings. Nimbus should ask for a scope covering the production SaaS platform and the processes that sustain it, excluding in writing anything that does not touch customer data. And sampling (step 5) is where you see whether the system is real: the auditor does not review all 22 controls to the same depth, they pick a few and chase them to the end. That is why a system that works withstands any sample, and a dressed-up one falls apart at the second question.

The biggest misunderstanding about audits is believing they consist of reviewing documents. A competent auditor does the opposite: they take a written assertion, ask for a specific sample and follow the trail to the end, looking for the point where the paper and reality diverge. Two simulated interviews, with what the auditor is checking in each question.

What these two interviews teach transfers to any audit: the auditor is not looking for perfection, they are looking for coherence between what is written, what people say and what the system shows; the incoherence is the finding. And an organisation that acknowledges its deviations with the record and the correction scores better than one that claims to have none and is contradicted by its own log.

How to respond to a finding. There are two ways of doing it badly and one of doing it well. Arguing — trying to convince the auditor it is not a finding — wastes time and credibility unless there is a documentable factual error, and it sometimes triggers a deeper review. Overreacting — accepting everything and promising to fix it next week — produces actions still open at follow-up, and an unfulfilled corrective action is worse than the original finding because it calls the whole system into question. The right approach is to understand exactly what the finding is, repeating it in your own words until the auditor confirms; to supply the evidence that perhaps was not found if it exists and is dated; to accept what is true; and to commit to a fix with a root cause, an owner and a realistic deadline.

Corrective action template:

The two elements that mark out a real action plan are 3 and 5. Without a root cause you fix the symptom and the finding reappears next year under another name — signing two overdue sets of minutes would have changed nothing. And without an effectiveness verification on a future date, the action is declared closed on the day it is implemented, exactly when you still do not know whether it works. It is the logic of 04-05 and 05-03: no retest, no closure.

ISO 27001 requires it (clause 9.2) and NIS2 pushes in the same direction, but its value predates any rule: it is the only way to know where you stand before somebody from outside tells you. The apparent obstacle is independence, and the minimum viable version is enough: whoever audits does not audit what they execute. With five people there are enough combinations:

When no independence is possible — Marta auditing processes she approves herself — the honest solution is to buy two days of external auditor a year (1,500-2,500 €) for that part and declare it in the report: hiding the lack of independence is a finding, declaring it is an acceptable scope limitation.

And the report template, deliberately short:

The positive aspects section is not a courtesy: an audit programme that only produces bad news stops being welcome, and then people start preparing the photograph instead of showing reality.

They are constantly confused, and confusing them leads to believing you are covered when you are not.

Both are necessary because they fail in different places. Pentest PT-2026-01 found the residual IDOR, which no management audit would have seen; and a management audit found that two accesses marked for revocation were still active, which no pentest would have looked at. A system can be immaculately configured and have nobody to maintain it; and it can have an exemplary ISMS on top of vulnerable infrastructure. An important clarification: the pentest of 05-03 is evidence, not an audit. It attests to the requirement of "regular verification of effectiveness" — article 32.1.d of the GDPR, clause 9 of ISO 27001 — which is why it appears in the last row of the matrix in section 3. Presenting it as a conformity audit is a mistake auditors spot immediately and one that exposes what the pentest does not look at: governance, contracts, training, records and decisions.

In 06-02 we saw how to answer them honestly; here, how to industrialise them, because they are the most frequent audit an SME undergoes and the one that scales worst: the first costs 20 hours and the fifth should cost 3. The reusable security pack, maintained by Marta and reviewed every six months:

The answer bank (faq.md) is what produces the saving: each question answered once, with its approved wording, its associated evidence and its review date. When a new questionnaire arrives, 80 % is answered by copying. Maintenance rule: every new answer goes into the bank the same day, or the saving never arrives. And a negotiating tip that saves weeks: when a customer sends 90 questions clearly designed for a supplier of a different size, offering the pack up front and asking what remains unanswered usually reduces it to ten specific questions; it is faster for both sides and it conveys maturity.

The status of each control is classified into four values, and the strict definition matters more than the metric: implemented (it exists, it operates and it has been verified within its frequency), partial (it exists but does not cover the whole population, or its verification has expired), not implemented (decided but not operating) and not applicable (justified in writing, with a business reason).

What matters is not the percentage: it is the degradation rule. A control verified outside its frequency automatically stops counting as implemented, without anyone having to decide it, so the number falls on its own when the work is abandoned instead of freezing at the 100 % of the day it was declared finished. It is the thesis of 06-01 turned into arithmetic. And the two traps that ruin a compliance programme, both subtle because they look like productivity: Auditing only what is easy to evidence. The controls that produce a nice report — encryption, MFA, patching — always get audited; the ones that do not — the quality of the access review, whether anyone really looks at the alerts, whether the runbook holds up under pressure — are taken on trust. The result is a green dashboard with the worst-covered risks precisely where there is no focus. Antidote: include at least one "hard" control in every cycle and genuinely test it — inject an alert and time the response, ask somebody to run a runbook unaided. Optimising for the audit instead of for the risk. It is the classic degeneration: you pick the control that will look good in the report, you tune the scope to exclude what is awkward, you massage a deadline. Every step is defensible on its own and the whole produces a certificate over a company that is not protected. Antidote: always keep two separate indicators, published together — compliance coverage (this section) and residual risk (04-01). When the first rises and the second does not fall, something is being optimised for the photograph.

• Confusing having a control with being able to prove it. The backups exist, but with no dated restore report you do not comply with 32.1.c or 32.1.d and, to an auditor, they do not exist. And do not reconstruct evidence before the audit: it costs three times as much, comes out incomplete, is not contemporaneous and an experienced auditor spots it from the suspicious uniformity of the documents.
• Evidence in ephemeral tools. Chat gets purged, e-mail leaves with the person, the spreadsheet on the desktop disappears: evidence lives in a repository with a declared retention. Closing actions on the day they are implemented and fixing the symptom. With no effectiveness verification on a future date the action is deferred, not closed; and with no root cause the finding comes back under another name. Arguing with the auditor, absent a documentable error, loses credibility and earns a deeper review. And do not hand a customer the full pentest report: it is an attack map; you hand over the executive summary and the retest confirmation, under confidentiality.
• Tip: store the evidence on the day you do the work. It costs zero minutes then and half a day three months later. It is the one rule in this lesson that, applied on its own, already pays for it.
• Tip: audit yourself first, and document what worked too. Finding a gap of your own costs the fix; having a third party find it costs the fix and explaining why you did not know. And a report that only brings bad news stops being welcome: then people prepare the photograph instead of showing reality.

Exercise 1 — Turning assertions into evidence

Marta has written four assertions to answer a customer: (1) "all our employees receive security training"; (2) "we periodically review who has access to customer data"; (3) "our backups are immutable and tested"; (4) "we detect anomalous access to our customers' data". For each one, state what specific evidence would back it up, whether it is automatable or requires human judgement, how often it must be generated and what question an auditor would ask to put it to the test.

Exercise 2 — A finding and its corrective action

At the September internal audit, the external auditor asks for a sample of the consultancy's (A-19) access requests over the last quarter. They find eleven logged sessions but only seven requests with prior authorisation: the other four were executed and logged, with no trace of who authorised them. Lucía explains that they were urgent weekend incidents and that she authorised them verbally. Classify the finding justifying the type, draft the complete corrective action with the six sections of the template, and explain why "from now on Lucía will send a confirmation e-mail" would be insufficient.

Exercise 3 — Designing the internal audit cycle that hurts most

Nimbus can only devote 6 hours to one internal audit cycle, and Marta wants it to be the one that yields the most information about real risk, not the one that produces the shiniest report. Choose the area, say which controls you would audit, how you would genuinely test each one (not by reviewing documents), what sample you would request and what you would expect to find. Justify why that area and not another.

Exercise 1

The cross-cutting lesson: all four assertions are true in many companies and none of them is demonstrable without the artefact in the second column. And in three of the four the auditor's question points at the same place: not at the control existing, but at its having been tested and at the hard sample — the new employee, the withdrawn access, the alert that never fired — being covered too. The fourth is the most fragile: a detection catalogue that has never fired is indistinguishable from one that does not work.

Exercise 2

Classification: MINOR nonconformity, with an argument for treating it as major. It is minor because the control exists, it is defined in POL-08 6.2.3, it is applied in 7 of 11 cases and the rest were logged, so there is no systemic failure. The argument for raising it is serious: it affects R-01, the worst-scoring risk, and the exact vector of the 02-06 incident was uncontrolled access by this very consultancy; a rigorous auditor could argue that a control failing 36 % of the time on the critical risk is not operating. The right response is not to argue about the classification, but to treat it with the seriousness of a major one.

Why "Lucía will send a confirmation e-mail" is insufficient, and the reasoning holds for almost any finding: (1) it does not attack the root cause — the problem is not that Lucía forgets to write, it is that there is no authorised path for emergencies and the system permits the shortcut; (2) it keeps the control procedural, that is, dependent on one person's memory under pressure on a Sunday night, which is exactly when memory fails (06-01); (3) Lucía cannot be the one who authorises her own access: that is not authorisation, it is self-service, and it removes the separation of duties that gives the control its meaning; (4) it adds no detection, so the next deviation would again be discovered nine months later in another audit; and (5) it produces no structured evidence, just a stray e-mail in a mailbox, which is exactly the kind of ephemeral evidence this lesson warns against. The general rule: if the corrective action depends on somebody remembering, it is not a corrective action.

Exercise 3

Area chosen: detection and response (C-07, C-08, C-09, C-17 and detections D-01…D-12). And the justification is what organises the whole exercise: it is the area where the distance between what is documented and what is real is systematically greatest. Access or encryption policies are easy to verify and are usually fine; by contrast, a twelve-detection catalogue written in a document and an immaculate runbook can coexist perfectly well with an inability to see an attacker for twenty days. That is exactly what happened in 02-06, and it is the area no customer questionnaire knows how to assess.

How I would genuinely test each control, in 6 hours:

The sample I would request, and the criterion is that the auditor chooses it, not the auditee: the last 10 alerts of any severity — not the ones Lucía proposes — following each one through to closure, and every S1 of the half-year. What I would expect to find, being realistic about an SME: that two or three detections have never been tested and one does not fire — a badly calibrated threshold, a change in log format, an expired collector credential — which is the most likely and most valuable finding; that low-severity alerts are closed with no comment, which makes it impossible to distinguish "reviewed and dismissed" from "ignored"; that the runbook has gaps of tacit knowledge — where a credential lives, who to call, which exact command — a finding that attacks R-09 directly and that no document review would have produced; and that the real MTTD is worse than the declared one, because the declared figure is calculated on the incidents that were detected and not on the ones detected late. Why this cycle and not another. A cycle on policies would produce a tidy report with two cosmetic observations and no new information. This one produces uncomfortable findings about the critical risk — the blindness that cost 20 days in 02-06 — it tests controls instead of reading them, and along the way it validates the work of module 5 under real conditions. It also has a side effect that on its own justifies the 6 hours: by the end, Iván knows how to run the runbook, so the audit has not only measured risk R-09, it has reduced it.

You have learned to separate two things that get confused at an expensive price: being secure and being able to prove it. With the two statements that must be held at once — compliance without security is theatre and security without evidence does not survive an audit, a customer, a change of personnel or itself — and with the economic argument that convinces anyone who sees this as bureaucracy: evidence is cheaper if it is generated while doing the work than if it is reconstructed afterwards; auditing is not expensive, reconstructing is expensive. You know what evidence is and what makes it valid: attributable, dated, intact, reproducible and retained, with the table of types and its examples drawn from the whole course — POL-02 approved, the A-02 bucket policy exported, the C-07 audit table, the outputs of trivy, prowler and lynis, the restore report with measured RTO, the PT-2026-01 record and its retest, the signed C-21 minutes, the closed onboarding ticket, the recertification matrix — fulfilling 05-07's promise that module 5 would keep generating exactly the material now needed. With the two selection criteria: prefer evidence the machine generates on its own, and remember that the most valuable evidence is the evidence that shows the control detected something and it was corrected.

You have the traceability matrix in its final form, with risk, requirement, policy, control, evidence, owner, frequency and last verification, as a table and as yaml that lives in the repository and is reviewed in pull requests; with the sum that justifies it to management: 15 hours a year to maintain it versus 40-60 to reconstruct it, and with incomplete material at that because the log rotated and the person left. You know how to automate collection with a collector that exports, seals with hashes, signs and stores in immutable storage, respecting the right boundary — you automate the verifiable fact, not the judgement — and ending with the list of what only a person can do.

You can distinguish the five types of audit and what is at stake in each, you know the full nine-step process with the two points where the outcome is decided — the scope and the sampling — and above all you know how a real auditor behaves: they do not review documents, they take an assertion, ask for a sample and follow the trail, looking for the incoherence between what is written, what people say and what the system shows. The two simulated interviews have taught you the questions that matter — the whole population versus a sample, the alternative emergency path, "delete it and make it pass" — and the most counter-intuitive lesson: acknowledging a deviation with its record and its correction scores better than claiming there are none.

You can classify findings — major, minor, observation, opportunity — respond without arguing or overreacting, and draft a corrective action plan whose two decisive sections are the root cause analysis and the effectiveness verification on a future date: without the first the finding comes back under another name, and without the second the action is declared closed exactly when you still do not know whether it works. You can set up internal auditing in a 38-person company with the minimum viable independence — whoever audits does not execute — and by buying two days of external auditor where there is none, with its annual programme and its report that also documents what worked, because a programme that only brings bad news stops being welcome. You can distinguish the technical audit from the management audit, you know they fail in different places and why the pentest is evidence, not an audit. And you know how to industrialise customer questionnaires with a three-tier pack — public, under confidentiality, and what is never handed over, because the full pentest report is an attack map. You close with the status-by-control dashboard and its automatic degradation rule, and with the two traps: auditing only what is easy to evidence and optimising for the audit instead of for the risk, whose antidote is publishing compliance and residual risk together.

And now notice a pattern that runs through this entire lesson. In the interview, Lucía knew where everything was. Iván could break a test to prove that CI reacts. The February alert was detected because somebody looked at the report. The out-of-flow account creation happened because a person was in a hurry on a Sunday. The runbook fails not because it is badly written, but because only one person knows what is not written in it. Behind every control, every piece of evidence and every finding there is a person who does or does not do something, and no traceability matrix corrects that. In Training and Awareness (06-05) we work on the factor that remains the main vector and also the best defence: why the objective is not that people know but that they do and above all that they report, how to design a programme that fits into an SME's real available time, how to run ethical phishing simulations and which metrics to read in them — the report rate above the click rate — and why blaming the person who falls for it destroys exactly the early detection we have spent the whole course trying to build.