Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Certification bodies treat internal audit quality as a proxy for whether the whole ISMS is real. This is how to build a program, run an audit, and write findings that stand up.
ISO/IEC 27001 clause 9.2 requires two distinct things: an audit program that covers the whole management system over a defined cycle, and individual audits run against defined criteria and scope by auditors who are objective and impartial. The program is a schedule with frequency, methods, responsibilities and reporting; the audit is a day or two of pulling real samples and writing what you found. The auditor cannot audit their own work, which at a small company means training someone from another function, swapping with a peer, or bringing someone in. Findings feed corrective action under clause 10.2, and audit results are a required input to management review. An internal audit report with no findings is the single most reliable way to attract a nonconformity of your own at stage 2.
Clause 9.2 has two parts. The first says you conduct internal audits at planned intervals to provide information on whether the ISMS conforms to your own requirements for it and to the requirements of the standard, and whether it is effectively implemented and maintained. That is the purpose statement, and the two halves of it matter: conformity to the standard is only one of the two tests, and conformity to your own documented requirements is the one that catches more.
The second part is about the program. You have to plan, establish, implement and maintain one or more audit programs covering frequency, methods, responsibilities, planning requirements and reporting. For each audit you define the audit criteria and scope. You select auditors and conduct audits in a way that ensures objectivity and impartiality. You ensure the results are reported to relevant management. And you retain documented information as evidence of both the program and the audit results.
Read those requirements as a list of artifacts and it becomes concrete. You need a program document, a plan per audit, working papers showing what was examined, a report per audit, a record of who audited and why they were impartial and competent, and evidence that management received the results. Six artifact types. Most organizations that fail 9.2 have the report and nothing else.
Note what the clause does not say. It does not prescribe a frequency, a sample size, a report format, a grading scheme, or that the auditor be external. All of those are your decisions, which means all of them have to be written down somewhere, because "the organization's own requirements" is the first test in the clause.
This is the distinction people collapse, and collapsing it is why so many internal audit files look thin. The audit program is a multi-audit schedule that answers: over what cycle does the entire ISMS get looked at, how often, by whom, using what methods, and how do results get reported and escalated. It is a governance document, approved once and revised as things change.
An individual audit is one execution: a defined scope, defined criteria, a plan, a set of samples, findings, and a report. A single audit almost never covers the whole standard, and it does not need to. What the program has to guarantee is that across its cycle, every clause and every applicable Annex A control has been audited at least once.
The two shapes that work are the single annual sweep and the split cycle. The single annual sweep is one audit per year covering everything, typically two to four days for a company under a hundred people. It is simpler to schedule and produces one report. The split cycle breaks the ISMS into three or four thematic audits spread across the year: for example access and identity in Q1, supplier and third-party management in Q2, development and change in Q3, incident, continuity and the management system clauses in Q4. Each is half a day to a day.
The split cycle is better for organizations that are actively changing, because it puts a real audit event in every quarter and findings surface early enough to fix before certification or surveillance. The single sweep is better where audit resource is a scarce external booking. Either is defensible. What is not defensible is a program that quietly leaves clauses uncovered because nobody ever mapped coverage.
Whichever you choose, the program document should contain a coverage matrix: clauses 4 through 10 down one side, applicable Annex A control groups down the other, and the audit occasion that covers each. That single table is what an auditor asks for when they want to know whether your program is complete, and producing it takes twenty minutes.
The standard says planned intervals, not annually. Annual full coverage is the practical floor because the certification cycle is annual and management review needs current audit results. Beyond that floor, weight the frequency by risk and by change.
Areas that earn more frequent audit: anything that changed materially in the last twelve months, anything that produced an incident, anything where the last audit found a nonconformity, and anything a customer or regulator has specifically asked about. Access management and change management usually earn extra attention in software companies because they are high-volume processes where drift is invisible until sampled.
Areas that can go on a longer cycle: stable, low-volume processes with few transactions to sample. Physical controls at a company with one leased office and no data centre are a genuine example. Auditing them annually is not wrong, it is just a poor use of a limited audit budget compared to sampling a quarter's worth of privileged access grants.
Write the rationale for the frequency into the program. A program that says "annual, all clauses" with no reasoning is acceptable. A program that says which areas are audited more often and why is better, and it demonstrates the risk-based thinking that runs through the rest of the standard.
The requirement is objectivity and impartiality of the audit process, and the plain-language version is that nobody audits their own work. The person who runs your access reviews cannot be the person who audits whether access reviews are being run. The person who wrote the incident response plan cannot be the person who concludes it is adequate.
At a company of twenty to two hundred people this is genuinely awkward, because the ISMS is usually run by one or two people and everything touches them. There are four workable answers. Cross-function: train someone from finance, legal, or engineering who does not own any security control to audit the security function, and have the ISMS owner audit something else. Peer swap: exchange internal audits with a comparable company under mutual NDA. External contractor: engage an independent auditor for the internal audit, which is legitimate and common and is not the same as your certification audit. Split responsibility: where the ISMS owner has to be involved for competence reasons, have them audit clauses they do not personally operate and bring someone else in for the rest.
What does not work is the ISMS owner auditing the whole ISMS and writing a note saying they were objective. Certification bodies see this constantly and it is one of the more common 9.2 findings.
Evidence the impartiality decision, do not just assert it. A one-page record naming the auditor, listing what they are responsible for in the business, and stating which areas they were therefore excluded from auditing, signed and dated, closes the question in the audit room in under a minute.
Clause 7.2 requires you to determine the competence needed for people whose work affects information security performance and to retain evidence that they have it. The internal auditor is squarely inside that requirement, and auditor competence is a finding that catches organizations out because they solved impartiality and stopped there.
Competence for an ISO 27001 internal auditor has two halves: knowing how to audit, and knowing enough about information security and about your business to recognize when an answer is wrong. The auditing half is teachable in a two to five day internal auditor course, and those courses are inexpensive relative to the cost of a nonconformity. ISO 19011 is the guidance standard for auditing management systems and is worth reading regardless of whether anyone takes a course.
The security half is harder to fake. An auditor who does not understand what an IAM role is will accept a screenshot that proves nothing. This is the argument for the cross-function approach failing in practice at technical companies, and for pairing: an independent non-technical auditor leading the audit, with a technically competent person who is also independent of the area under audit acting as a technical expert. ISO 19011 explicitly contemplates audit teams with technical experts, so this is a normal structure rather than a workaround.
Keep the competence record with the audit file: the auditor's CV or role history, any internal auditor training certificate with a date, and a line stating what competence was required and how it was met. That is the whole artifact.
The audit plan is a one-page document issued before the audit, usually a week ahead. It states the scope, meaning which parts of the ISMS and which locations or systems are being examined. It states the criteria, meaning what you are auditing against: the standard, your own policies by name and version, and any contractual or legal requirements in play. It states the dates, the auditor, the people to be interviewed, and the documents needed in advance.
Criteria are the part most often written vaguely, and vague criteria produce findings you cannot defend. "ISO 27001" is not criteria. "ISO/IEC 27001:2022 clauses 9.1 to 9.3, Annex A controls A.5.15 to A.5.18, the Access Control Policy v3.1, and the customer security schedule in the standard MSA" is criteria. When you later write a finding, the criterion is the first thing the finding cites, so if it was not in the plan the finding has no anchor.
Send the plan in advance and ask for documents in advance. Reading policies during the audit wastes the interview time you actually need. A good pre-read pack is the current SoA, the risk register, the policies in the audit scope, the previous audit report, and the corrective action register.
Always open with the previous audit's findings. Checking whether prior corrective actions were implemented and were effective is both good practice and directly relevant to clause 10.2, which requires you to review the effectiveness of corrective actions taken. It is also usually the fastest finding of the day.
An audit that consists of interviews and document review is not an audit, it is a conversation. The evidence that makes an internal audit credible is samples: specific records, chosen by the auditor rather than offered by the auditee, tested against the criteria.
There is no prescribed sample size in ISO 27001. What works at startup and mid-market scale is small and deliberate: for a control that runs monthly or quarterly, test every occurrence in the period, because there are only four to twelve of them. For high-volume populations such as joiners, leavers, access grants, changes, or vulnerability remediation tickets, five to ten items chosen across the period is enough to expose a broken process, and if two of ten fail you stop sampling and write the finding rather than testing thirty more.
Choose the sample from the source of truth, not from a list the auditee prepares. For leavers, take the list from the HR or payroll system rather than from the person who runs offboarding. For changes, take them from the version control or ticketing system. The point of independent selection is that it catches the population that is missing from the auditee's own list, which is usually where the failure lives.
Record the sample in the working papers by identifier: ticket numbers, employee identifiers with names redacted if you prefer, change references, dates. "Tested a sample of access reviews" is not a working paper. "Tested access reviews for the production AWS account dated 2026-01-14, 2026-04-09 and 2026-07-11, and the review for Q2 was completed 39 days after the quarter end against a policy requirement of 15 days" is a working paper and it already contains a finding.
Working papers are documented information under 9.2 and clause 7.5. Keep them. Certification body auditors do ask for them when the report looks thin, and a report backed by dated sample references reads completely differently from one that is not.
A finding has three parts and it fails if any one is missing. The requirement, meaning the exact criterion that was not met, cited to a clause, control, or named policy section. The evidence, meaning the specific record you examined, with identifiers and dates. The statement of nonconformity, meaning one sentence saying plainly what does not conform.
Written out, a usable finding looks like this. Requirement: the Access Control Policy v3.1 section 4.2 requires quarterly review of privileged access to production within 15 days of quarter end. Evidence: the Q2 2026 privileged access review for the production AWS account was completed on 8 August 2026, 39 days after quarter end; the Q1 review has no completion record. Nonconformity: privileged access reviews are not being performed within the interval required by the organization's own policy.
Three habits ruin findings. The first is writing the fix instead of the finding: "should implement automated access review tooling" is a recommendation, and the auditee's job is to determine the correction, not yours. The second is writing an opinion with no evidence: "access review process appears weak" gives the corrective action process nothing to work with. The third is bundling: five unrelated failures under one finding number, which makes root cause analysis impossible and lets four of them close silently when the fifth is fixed.
Separate nonconformities from observations and from opportunities for improvement, and define all three terms in your audit procedure so the grading is consistent between audits. A nonconformity is a failure to meet a requirement. An observation is something that meets the requirement now but is trending towards failing, or a single lapse in an otherwise sound process. An opportunity for improvement is a suggestion with no requirement behind it, and it does not need a corrective action.
One thing worth being precise about: ISO/IEC 27001 itself does not define major and minor nonconformity. Clause 10.2 talks about nonconformities without grading them. The major and minor distinction comes from the certification scheme, from the rules certification bodies work under, and it is those rules that decide what happens to your certificate.
The working definitions certification bodies use are consistent enough to plan around. A major nonconformity is the absence or total breakdown of a required part of the management system, a failure that puts the integrity of the ISMS or the security of information in real doubt, or a group of minor nonconformities against the same requirement that together show the process is systemically not working. A minor nonconformity is a single lapse or isolated failure in a process that otherwise exists and functions.
The consequences differ sharply. At an initial certification audit, a major generally blocks the certificate until the corrective action has been implemented and verified, which often means a follow-up visit and a delay measured in weeks or months. A minor is normally cleared by submitting a corrective action plan that the certification body accepts, with implementation verified at the next surveillance visit. At surveillance, an unresolved major can escalate towards suspension of the certificate.
Grading your own internal findings as major and minor is optional but useful, because it forces the same conversation internally that the certification body will have externally. If you do it, use the same definitions and write them into your audit procedure. Do not invent a third grade like "critical" that has no external counterpart, because it creates confusion at the point where you hand the register to the certification body.
The practical value of finding your own major before the certification body does is enormous. A major you found in March, fixed by June, and can demonstrate the effectiveness of by September is evidence that the management system works. The same failure found by the certification body in September is a delayed certificate.
The report is issued to relevant management, which the standard requires explicitly. At a small company that means the executive who owns the ISMS plus the owners of any area with findings. Send it in writing, dated, and keep evidence it was sent, because "results reported to relevant management" is a testable requirement and an email is the easiest possible evidence.
A workable report is five sections: scope and criteria, dates and people, method including what was sampled, findings with their grading, and a conclusion on whether the ISMS conforms and is effectively implemented in the audited areas. Two to six pages. Longer reports are not better reports; the working papers carry the detail.
Every nonconformity then becomes an entry in the corrective action register under clause 10.2. That clause requires you to react to the nonconformity and control or correct it, deal with the consequences, evaluate whether action is needed to eliminate the cause so it does not recur, implement that action, review its effectiveness, and update the ISMS if necessary. The register therefore needs six things per entry: the correction, the root cause, the corrective action, the owner, the due date, and the effectiveness review date.
The effectiveness review is the step almost everyone omits, and it is the step certification bodies specifically look for. Schedule it 30 to 90 days after closure, put it in the calendar, and record the verdict in writing even when the verdict is simply that the control has run correctly three times since. A corrective action closed with no effectiveness check is an open item as far as an experienced auditor is concerned.
Root cause does not require a formal methodology at this scale. Three rounds of asking why, written down in three lines, beats a blank fishbone template. What matters is that the recorded cause explains the failure rather than restating it. "The access review was late because nobody did it" is a restatement. "The access review was late because it was tracked in a personal calendar reminder belonging to someone who was on parental leave, and there was no backup owner" is a cause you can act on.
Internal audit results are one of the required inputs to management review under clause 9.3. That link is not decorative. It is the mechanism by which findings reach people with budget, and a certification body checks it by comparing the audit report to the management review minutes.
What has to arrive at the review is not the report itself but a summary that supports decisions: how many findings, of what grade, in which areas; which prior findings are still open and why; which findings have had their effectiveness confirmed; and any trend across audits. Trend is the input executives can actually act on. Three consecutive audits finding late access reviews is a resourcing decision, not an access review problem.
The failure pattern is a management review whose minutes say "internal audit report was noted". That records attendance, not consideration. The minutes should show the findings were discussed and should carry an output: a decision, an owner, a date. Where the review decided to accept a finding without action, record that decision and the reasoning, because a documented and deliberate acceptance is defensible and a silent one is not.
Time the program so the last audit of the cycle lands with enough distance from management review for findings to be summarized and, ideally, for some corrective action to be underway. An audit that finished two days before the review produces minutes that can only say "noted".
At stage 1 the certification body reads the internal audit program and the most recent audit report, and they use them to judge whether you are ready for stage 2. An organization that has never run an internal audit is not ready for stage 2, full stop, because a required clause has never been operated.
They check five things, in roughly this order. That a program exists and covers the full standard and the applicable Annex A controls across its cycle. That the audits in the program actually happened on the dates claimed. That the auditor was independent of what they audited and competent to audit it. That the audit tested real evidence, which they establish by asking for working papers or by asking the auditor what they sampled. And that findings went into corrective action and were tracked to closure with an effectiveness check.
They are also reading for calibration. A certification body auditor who finds four nonconformities in areas your internal audit passed clean has learned that your internal audit does not detect problems, and they will widen their own sampling accordingly. The reverse is also true: an internal audit that found and closed real issues buys goodwill and, more practically, shortens the areas they feel obliged to dig into.
This is why the zero-findings report is so damaging. It is not that finding nothing is impossible, it is that finding nothing in a first-year ISMS at a growing company is not credible, and it invites the certification body to test whether the internal audit was performed at all.
Program covers the standard but not the applicable Annex A controls, or covers Annex A but skips clauses 4 through 10. The management system clauses are where most nonconformities live and they are the ones internal audits most often ignore.
A program document that is really just a calendar entry. Frequency, methods, responsibilities, planning requirements and reporting are all named in the clause, so all five need a sentence.
The audit happened but there are no working papers, so the report cannot be substantiated. This is recoverable only by running the audit again.
Findings raised but never entered into the corrective action register, or entered and closed with no root cause and no effectiveness review.
The auditor audited an area they own, with no impartiality record explaining the arrangement.
Audit criteria written as "ISO 27001", so findings cite nothing specific and cannot be defended when challenged.
The audit ran late in the year and the management review minutes note the report without discussing it, breaking the link the certification body is looking for.
The same finding recurring across cycles with a new corrective action each time. Recurrence is evidence the root cause analysis is not working, and it is a stronger signal to an auditor than the original finding ever was.
| Area under audit | Sample the auditor should pull | What a finding looks like here |
|---|---|---|
| Risk assessment and treatment (6.1, 8.2, 8.3) | The two most recent dated risk register snapshots, plus five risks traced from register to SoA to treatment plan line. | A high risk with no control pointed at it, or treatment actions with no revised dates against a year of slippage. |
| Access management (A.5.15 to A.5.18, A.8.2) | Every periodic access review in the period, plus ten joiners and ten leavers taken from the HR system, not from the IT list. | A leaver with active credentials, or a review completed outside the interval the policy itself requires. |
| Change and development (A.8.25 to A.8.32) | Ten production changes taken from the version control or deploy log, tested for review, approval and separation of environments. | Changes merged without the review the policy requires, or an emergency change path used routinely rather than exceptionally. |
| Vulnerability management (A.8.8) | The scan reports for the period plus the remediation tickets for every critical and a sample of highs, tested against the stated SLA. | Criticals open past the SLA with no risk acceptance recorded, or asset coverage that does not match the asset inventory. |
| Supplier management (A.5.19 to A.5.23) | The vendor inventory reconciled against expense or SSO data, plus the review files for five critical vendors. | A production dependency absent from the inventory, or a critical vendor whose assurance report was collected but never read. |
| Incident management (A.5.24 to A.5.28) | Every incident in the period end to end, or five if there were many, plus the most recent test or tabletop. | Incidents with no post-incident record, or a notification timeline that does not match what customer contracts promise. |
| Awareness and people (A.6.1 to A.6.6) | Training completion export reconciled to the current headcount list, plus five onboarding files. | Completion measured against a stale roster, so the percentage is high but the denominator is wrong. |
| Monitoring and logging (A.8.15, A.8.16) | The logging configuration for each in-scope environment, plus a walkthrough of one alert from trigger to human response. | Logging enabled in production but not in an environment holding a copy of customer data, contradicting the SoA status. |
| Management system clauses (4, 5, 7, 9, 10) | Scope statement, policy, competence records, metrics reports, last management review minutes, corrective action register. | Objectives with no measurable target, or corrective actions closed with no effectiveness review recorded. |
The standard says at planned intervals rather than naming a frequency, so you set it and then have to meet it. In practice full coverage of the standard and the applicable Annex A controls at least once a year is the working floor, because the certification cycle is annual and management review needs current audit results. Splitting that coverage into three or four shorter audits across the year works well and surfaces problems earlier.
You can do it yourself. The requirement is objectivity and impartiality, not externality. What you cannot do is have someone audit their own work, so the person who runs the ISMS cannot audit the ISMS. Small companies solve this by training someone from an unrelated function, swapping audits with a peer company, or hiring an independent auditor for the internal audit, which is separate from and cheaper than the certification audit.
The internal audit is yours: you set the program, choose the auditor, own the findings, and nobody outside sees it unless you show them. The certification audit is performed by an accredited certification body and results in the certificate. The certification body reads your internal audit records as evidence that clause 9.2 is being met, and it uses the quality of your internal audit to calibrate how deeply it samples elsewhere.
ISO 27001 itself does not define the grades; they come from the certification scheme. In practice a major is the absence or total breakdown of a required part of the management system, or several minors against the same requirement showing a systemic failure. A minor is an isolated lapse in a process that otherwise exists and works. A major at initial certification generally blocks the certificate until corrective action is implemented and verified; a minor is usually cleared with an accepted corrective action plan.
In a first-year or fast-growing ISMS, yes. It is not impossible to find nothing, but it is not credible, and the certification body will respond by testing whether the audit was genuinely performed and by widening its own sampling. A report that names real findings and shows them tracked to closure with an effectiveness check does more for your credibility than a clean one.
No size is prescribed. For controls that run monthly or quarterly, test every occurrence in the period since there are only a handful. For high-volume populations such as joiners, leavers, access grants or changes, five to ten items spread across the period is enough to expose a broken process. Select the sample yourself from the source system rather than accepting a list prepared by the person being audited.
The audit program, the plan for each audit with its scope and criteria, working papers showing what was sampled with identifiers and dates, the report, evidence that the report reached management, and the record of auditor competence and impartiality. Clause 9.2 requires documented information as evidence of both the program and the results, and thin working papers are the most common gap.
Audit results are a required input to management review under clause 9.3, and every finding should also be an entry in the corrective action register under clause 10.2. What goes to the review is a summary supporting decisions: counts by grade and area, prior findings still open, effectiveness checks completed, and any trend across audits. The minutes then need to show a decision with an owner and a date, not just that the report was noted.
traztech Workspace has all 93 Annex A controls and 25 ISMS clauses (4-10) of ISO 27001 written in plain English, with what the standard asks for, what to do about it, and somewhere to attach the proof. You answer them, it scores you, and nothing is locked behind an upgrade.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We run ISO 27001 internal audits against real samples, write findings your certification body will recognize, and hand you the working papers as well as the report.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.