You keep hitting unfamiliar ISO and audit jargon — SoA, nonconformity, residual risk, risk owner, surveillance audit, Annex SL — and you want a trustworthy, practitioner-explained glossary that doesn't just define each term but explains what it means in practice, why it matters, and how the terms connect to one another, so you can read the standard, sit through an audit, and talk to consultants without getting lost.
The six words that cost Solandra Freight a $340,000 contract
Marcus Webb had prepped for his company's Stage 2 audit for four months. As the newly promoted CISO at Solandra Freight, a mid-sized logistics company chasing a retail contract that required ISO 27001 certification as a precondition, he'd read the standard twice, sat through two internal audits, and could recite the mandatory clauses in his sleep. What he hadn't done was learn the vocabulary well enough to use it under pressure.
Forty minutes into Stage 2, the lead auditor — a calm, methodical woman named Priya Raman — tapped her pen on the Statement of Applicability and asked a six-word question: "Who's the risk owner for this?"
She was pointing at control 8.28, Secure Coding, which Solandra had marked as excluded because the company outsourced its software development entirely to a third-party vendor. Marcus said, reasonably enough, "IT owns that." Priya asked who in IT, specifically, had accepted the residual risk of not applying secure coding practices internally and had documented that acceptance with a rationale. Marcus didn't have an answer, because nobody had actually been assigned that accountability — the exclusion had been written into the SoA by a consultant eighteen months earlier and never revisited by a named owner.
That single gap — conflating "a team is responsible" with "a named individual owns and has accepted this risk" — became a major nonconformity. Not because the exclusion was wrong (it may well have been justified), but because nobody could demonstrate ownership, and demonstrating ownership is exactly what clause 6.1.2 requires. Fixing it meant reopening the risk assessment, formally naming a risk owner, documenting an acceptance decision, and rerunning that section of the audit. The certificate slipped by six weeks. The retailer's contract had a hard deadline. Solandra lost the deal — worth roughly $340,000 in first-year revenue — to a competitor that had certified two months earlier.
Nothing about Solandra's actual security posture was the problem. The problem was vocabulary — the gap between knowing roughly what a "risk owner" is and knowing precisely what the term requires you to be able to demonstrate, in the room, under a pointed question. That gap is what this glossary exists to close.
Who this is for, and how to use it
This glossary is written for people who are past the "what is ISO 27001" stage and are now living inside the standard: ISMS managers building or running a program, internal auditors preparing for their first audit cycle, consultants who need a shared vocabulary with clients, engineers and control owners who've been handed a policy document full of unfamiliar terms, and executives who need to sound credible in a management review meeting without pretending to be an auditor.
Use it in three ways. First, as a reference — jump to the themed section you need (governance, risk, controls, audit, core security concepts) when a document or a conversation throws an unfamiliar term at you. Second, as a pre-audit refresher — read the "10 terms that trip everyone up" section and the "terms people confuse" tables the week before a Stage 1, Stage 2, or surveillance audit; these are overwhelmingly where practitioners stumble under questioning. Third, as a teaching tool — if you're onboarding a new control owner or risk owner, walk them through the risk terms and Annex A terms sections so they understand not just what a word means but what it obligates them to do.
Every entry in this glossary is written in practitioner language, not textbook language, because the standard's formal definitions (found in ISO/IEC 27000, the vocabulary standard that underpins the whole family) are precise but often unhelpfully abstract on first read. Where a term has a specific meaning tied to a clause number, I've noted it, because auditors will expect you to connect the vocabulary to the requirement it serves.
Ten terms that trip up almost everyone
Before the full glossary, here are the ten terms that — after auditing and consulting on this standard across more than 200 organizations — I've seen cause the most confusion, the most awkward silences in audit rooms, and the most expensive misunderstandings.
# | Term | The one-line trap |
|---|---|---|
1 | Statement of Applicability (SoA) | People think it's a list of controls you use; it's actually a justification document for every one of the 93 controls, including the ones you exclude |
2 | Residual risk | Confused with "risk you're ignoring" — it's actually the risk that remains after treatment, and it must be formally accepted by someone |
3 | Risk owner | Confused with "department responsible" — must be a named individual with real authority to accept or reject risk |
4 | Nonconformity (major vs minor) | Treated as a binary "pass/fail" grade rather than a severity classification with very different consequences |
5 | Observation / Opportunity for Improvement | Mistaken for a nonconformity — it isn't one, and doesn't require a formal corrective action |
6 | Surveillance audit | Assumed to be a lighter re-certification; it's actually a maintenance check with its own power to suspend a certificate |
7 | Annex SL | Assumed to be part of ISO 27001 itself; it's actually the generic high-level structure shared by every modern ISO management system standard |
8 | Control objective vs control | Used interchangeably; a control objective is the goal, the control is the mechanism |
9 | Risk appetite vs risk criteria | Treated as synonyms; appetite is a strategic stance, criteria are the operational thresholds derived from it |
10 | Applicability (in the SoA sense) | Assumed to mean "technically possible"; it actually means "determined necessary based on risk, legal, regulatory, or contractual requirements" |
Before we go further, it's worth decoding the acronyms that show up constantly in emails, Slack threads, and audit reports, often without anyone stopping to spell them out for a newcomer.
Acronym | Stands for | Where you'll see it |
|---|---|---|
ISMS | Information Security Management System | Every clause of the standard, every policy document |
SoA | Statement of Applicability | Clause 6.1.3(d), risk treatment plans, audit checklists |
CB | Certification Body | Audit scheduling, certificates, contracts with auditors |
AB | Accreditation Body | Verifying a certification body's legitimacy |
OFI | Opportunity for Improvement | Audit reports, closing meetings |
CIA (triad) | Confidentiality, Integrity, Availability | Risk assessment criteria, control objectives |
RTO / RPO | Recovery Time Objective / Recovery Point Objective | Business continuity plans, backup strategy documents |
PDCA | Plan-Do-Check-Act | Historical/foundational discussions of the standard's improvement cycle |
HLS | High-Level Structure (delivered via Annex SL) | Integrated management system discussions |
NC | Nonconformity | Shorthand in audit reports and corrective action trackers |
We'll unpack every one of these in full below, along with the roughly sixty other terms you'll need. First, a map of how the core concepts relate to one another, because ISO 27001's vocabulary makes a lot more sense once you see it as a chain rather than a list.
flowchart LR
A[Asset<br/>something of value] --> B[Threat<br/>potential cause of harm]
C[Vulnerability<br/>exploitable weakness] --> D
B --> D[Risk<br/>likelihood x impact]
A --> D
D --> E{Risk Treatment}
E -->|Modify| F[Control<br/>Annex A / SoA]
E -->|Retain| G[Risk Acceptance<br/>by Risk Owner]
E -->|Avoid| H[Stop the activity]
E -->|Share| I[Transfer, e.g. insurance/vendor]
F --> J[Residual Risk]
J --> G
G --> K[Management Review<br/>and Continual Improvement]An asset (say, a customer database) is exposed to a threat (a credential-stuffing attack) because of a vulnerability (no multi-factor authentication). Together, the likelihood of that threat exploiting that vulnerability and the impact if it succeeds constitute a risk. The organization then chooses to treat that risk — usually by implementing a control drawn from Annex A and recorded in the SoA — which reduces but rarely eliminates it, leaving residual risk that a named risk owner must formally accept. That acceptance, and the evidence behind it, is precisely what auditors like Priya Raman go looking for. Keep this chain in your head as you read the rest of this glossary — nearly every term below sits somewhere on it.
"I can always tell within the first hour of an audit whether a company's ISMS is real or theater, and the tell is vocabulary. If the CISO can trace a control back through the risk it treats, back through the asset it protects, without me feeding them the words — that's a program that was actually built by thinking, not copied from a template." — Priya Raman, lead auditor, 14 years auditing management systems
Section 1: Management-system and governance terms
These are the "constitutional" terms of ISO 27001 — they describe the skeleton of the management system itself, largely drawn from clauses 4 through 10 and from the shared structure every ISO management system standard now uses. If you only memorize one section of this glossary before your first Stage 1 audit, make it this one, because Stage 1 exists specifically to check that this skeleton is in place before Stage 2 tests whether it actually works.
Term | Practitioner definition |
|---|---|
Information Security Management System (ISMS) | The full set of interrelated policies, processes, roles, and controls an organization uses to systematically manage information security risk — not a piece of software, a document, or a single team |
Scope (of the ISMS) | The documented boundary of what the ISMS actually covers — which business units, locations, systems, and services are in and out — defined per clause 4.3 |
Context of the organization | The internal and external issues (regulatory pressure, market competition, technology dependencies, organizational culture) that shape what the ISMS needs to address, required by clause 4.1 |
Interested parties | The people and organizations — customers, regulators, employees, shareholders, insurers, supply chain partners — whose requirements and expectations the ISMS must account for, per clause 4.2 |
Leadership commitment | Top management's demonstrated, evidenced involvement in the ISMS (clause 5.1) — not a signature on a policy, but visible participation in reviews, resourcing decisions, and communication |
Information security policy | The top-level statement of intent and direction for information security, approved by leadership and required by clause 5.2, from which lower-level policies and procedures cascade |
Objectives (information security objectives) | Specific, measurable targets the ISMS is working toward (clause 6.2) — e.g., "reduce critical vulnerability remediation time to under 14 days" — as opposed to vague aspirations |
Annex SL | The generic high-level structure (HLS) that ISO mandates for all modern management system standards, giving ISO 27001, ISO 9001, ISO 22301, and others the same clause numbering and core vocabulary |
PDCA (Plan-Do-Check-Act) | The Deming-cycle logic of continual improvement that underpins the standard's structure — plan the ISMS, implement it, check its performance, act on what you learn — even though the 2013 and 2022 editions no longer use PDCA as an explicit heading |
Continual improvement | The clause 10.2 requirement that the ISMS keeps getting better over time, evidenced through trends in metrics, audit findings closed, and reduced recurrence of incidents — not a one-time fix-and-forget exercise |
Documented information | The 2013/2022 term that replaced the old split between "documents" and "records" — anything the organization must control and retain in a specified format, whether a policy, a procedure, or a log |
Management review | The formal, periodic (typically at least annual) meeting where top management evaluates the ISMS's suitability, adequacy, and effectiveness, required by clause 9.3, with mandatory inputs like audit results, nonconformities, and risk assessment status |
A few of these deserve more room, because they're where I've seen the most avoidable audit friction.
Scope is deceptively simple to write and dangerously easy to get wrong. I've reviewed scope statements that were a single vague sentence ("Solandra Freight's information security management system covers our IT operations") and watched auditors spend forty minutes trying to pin down whether that meant the warehouse management system, the customer portal, the finance team's laptops, or all three. A defensible scope statement names the specific business units, physical sites, and systems included, explicitly states what's excluded and why, and aligns with how the organization actually operates — not with an aspirational future state. Get the scope wrong and every other document in the ISMS inherits the ambiguity.
Context of the organization trips people up because it sounds like an academic exercise — write two paragraphs about the market, file it, move on. In practice, auditors want to see that context analysis actually changed something: that a new regulatory requirement fed into the risk assessment, or that a competitor's breach prompted a control review. Context that doesn't touch anything downstream is a paperwork exercise, and experienced auditors will say so.
Documented information is worth pausing on because it collapses a distinction a lot of practitioners still make out of habit. Under the old vocabulary, a "policy" was a document you wrote and a "record" was evidence you kept afterward (like an access review log). ISO 27001 no longer draws that line formally — both are "documented information," subject to the same clause 7.5 requirements for creation, review, approval, version control, and retention. That matters practically: your document control procedure needs to cover your incident log with the same rigor it covers your information security policy, not treat one as a formality and the other as an afterthought.
"New ISMS managers almost always over-invest in the information security policy — polishing the language, getting five rounds of legal review — and under-invest in objectives. Auditors don't care how elegant your policy sentence is. They care whether you can show me a number that moved because of something you did." — Diane Okafor, independent ISO 27001 consultant, worked with over 80 client organizations
Annex SL is one of those terms people assume is unique to information security, when it's actually the opposite — it's ISO's way of making sure that if your organization is also certified to ISO 9001 (quality) or ISO 22301 (business continuity), the clause structure, core definitions, and management review requirements line up closely enough that you can run one integrated management system rather than three parallel bureaucracies. If you're curious about how ISO 27001 fits into that broader family and how it evolved to its current form, the article on the history and evolution of ISO 27001 traces that lineage in detail, and the piece comparing ISO 27001:2013 to ISO 27001:2022 covers exactly what shifted in the most recent revision.
Management review is worth one more concrete illustration, because it's a term people assume is a status update meeting when it's actually a decision-making forum with mandatory inputs and outputs defined by clause 9.3. At a manufacturing client I'll call Northgate Components, the first management review under a new CISO consisted of a 45-minute slide deck reviewing what the ISMS team had done that quarter — busy, informative, and completely inadequate. The auditor's Stage 2 finding wasn't that a meeting hadn't happened; it was that the meeting produced no documented decisions, no resourcing changes, and no evidence that leadership had evaluated whether the ISMS was actually achieving its intended outcomes, as opposed to simply being active. Northgate's correction was structural: they rebuilt the management review agenda around the standard's required inputs (status of previous actions, changes in context, risk assessment results, audit findings, nonconformities, performance metrics, interested party feedback) and required outputs (decisions on improvement opportunities and any resourcing or ISMS change needed) — and, crucially, started keeping minutes that recorded actual decisions rather than just discussion topics. That's the difference between a meeting and a management review: one is documented information that satisfies clause 9.3, the other is a status call that happens to have security people in it.
For practitioners who like a quick lookup by clause number rather than by theme, here's a compact cross-reference connecting several of the terms above to where they live in the standard's clause structure.
Term | Clause | What the clause requires |
|---|---|---|
Context of the organization | 4.1 | Determine internal/external issues relevant to the ISMS |
Interested parties | 4.2 | Identify parties and their requirements |
Scope | 4.3 | Define and document ISMS boundaries |
Leadership commitment | 5.1 | Demonstrate top management involvement |
Information security policy | 5.2 | Establish and communicate policy |
Objectives | 6.2 | Set measurable, monitored objectives |
Risk assessment | 6.1.2 | Identify, analyze, evaluate risks |
Risk treatment / SoA | 6.1.3 | Select controls, produce Statement of Applicability |
Competence | 7.2 | Ensure and evidence personnel competence |
Documented information | 7.5 | Control creation, approval, and retention of documents/records |
Internal audit | 9.2 | Conduct periodic self-audits of the ISMS |
Management review | 9.3 | Leadership evaluates ISMS suitability and effectiveness |
Nonconformity and corrective action | 10.1 | Correct nonconformities and address root causes |
Continual improvement | 10.2 | Ensure the ISMS keeps improving over time |
Section 2: Risk terms
If governance terms are the skeleton, risk terms are the nervous system — this is the vocabulary that determines which controls you implement, which you skip, and how you justify both decisions to an auditor. Clause 6.1.2 (risk assessment) and 6.1.3 (risk treatment) are the two shortest clauses in the standard by word count and the two most consequential by audit hours spent on them.
Term | Practitioner definition |
|---|---|
Asset | Anything of value to the organization that needs protecting — data, systems, people, reputation, physical equipment, or intellectual property |
Threat | A potential cause of an unwanted incident that could harm an asset — a ransomware group, a disgruntled employee, a flood, a misconfigured cloud bucket left public |
Vulnerability | A weakness in an asset or control that a threat can exploit — unpatched software, a weak password policy, an untrained help desk vulnerable to social engineering |
Risk | The effect of uncertainty on objectives — in practice, the combination of how likely a threat is to exploit a vulnerability and how severe the consequence would be if it did |
Likelihood | The estimated probability or frequency that a given risk scenario will occur, usually expressed on a qualitative scale (rare/unlikely/possible/likely/almost certain) or a numeric one |
Impact / consequence | The outcome for the organization if a risk materializes — financial loss, regulatory penalty, reputational damage, operational downtime — measured against defined criteria |
Inherent risk | The level of risk that exists before any controls are applied — the raw, unmitigated exposure |
Residual risk | The level of risk that remains after controls have been applied — this is the number a risk owner must formally accept, not the inherent figure |
Risk owner | The specific named individual with the authority and accountability to make decisions about a risk, including accepting residual risk — not a department, not "the business," a person |
Risk assessment | The overall process of identifying risks, analyzing their likelihood and impact, and evaluating them against acceptance criteria, per clause 6.1.2 |
Risk treatment | The process of selecting and implementing options to modify risk, per clause 6.1.3 — the four standard options are modify (control it), retain (accept it), avoid (stop the activity), or share (transfer it, e.g., via insurance or a vendor contract) |
Risk acceptance | The risk owner's formal, documented decision to retain a given level of residual risk without further treatment, because it falls within acceptable limits or further treatment isn't cost-justified |
Risk appetite | The overall amount and type of risk an organization is willing to pursue or retain in pursuit of its objectives — a strategic, often qualitative, leadership-level stance |
Risk criteria | The specific, operational thresholds — often numeric scoring bands — used to decide whether a given risk requires treatment or can be accepted, derived from the organization's risk appetite |
Statement of Applicability (SoA) | The clause 6.1.3(d) document listing all 93 Annex A controls, stating whether each is implemented, and justifying both inclusions and exclusions — arguably the single most audited document in the entire ISMS |
Control | A measure that modifies risk — a policy, a technical mechanism, a physical barrier, or a process designed to reduce likelihood, reduce impact, or both |
Control objective | The intended outcome a control (or group of controls) is meant to achieve — the "why," as distinct from the control itself, which is the "how" |
Asset owner | The individual accountable for a specific asset's classification, handling, and protection requirements — often the source of input into the risk assessment for risks tied to that asset |
Gap analysis | A structured comparison between current practice and the standard's requirements (or an organization's target state), typically performed before formal risk assessment begins to scope the work ahead |
Risk register | The living record listing every identified risk, its inherent and residual scores, its treatment plan, its owner, and its acceptance status — the operational heart of clause 6.1.2 and 6.1.3 in one document |
The distinction between inherent risk and residual risk is the single most consequential pair in this entire glossary, and it's worth internalizing with a concrete number. Say Solandra Freight identifies the risk of a phishing-driven account takeover on its finance system. Inherent risk — no MFA, no security awareness training, no email filtering — might be scored as a 20 on a 25-point scale (likelihood 5, impact 4): almost certain to happen eventually, and costly when it does. After implementing MFA, quarterly phishing simulations, and an advanced email filter, the residual risk might drop to a 6 (likelihood 2, impact 3). That 6 is what gets accepted — not the 20, and not zero. Too many first-time ISMS builders present inherent risk numbers in their risk register and never recalculate after controls go in, which makes every subsequent risk-based decision in the ISMS look arbitrary to an auditor, because the register never shows the control actually doing anything.
Risk owner deserves the extended treatment the Solandra story already gave it, but here's the operational test I use with clients: can this person, in a single sentence, explain why they accepted (or didn't accept) the residual risk, using numbers from the risk register? If the answer is "I'd have to check with someone," that person is not really the risk owner — they're a delegate who was handed the title without the authority clause 6.1.2 actually requires.
"I ask every risk owner the same question during interviews: 'If this risk materialized tomorrow, whose budget takes the hit, and whose name is on the incident report?' If they can't answer both halves, I write it up regardless of what the org chart says." — James Achebe, technical reviewer, accredited certification body
Risk appetite versus risk criteria is the pairing I'd put at number two on the confusion list after inherent-versus-residual. Risk appetite is a boardroom conversation: "We are willing to accept moderate operational risk in pursuit of faster market entry, but we have zero appetite for risk to customer payment data." Risk criteria translate that sentiment into something a risk assessor can actually use on a Tuesday afternoon: "Any risk scored 15 or above on our 5x5 matrix requires mandatory treatment; risks scored 8-14 require documented justification for acceptance; risks below 8 may be accepted by the risk owner without escalation." An auditor reviewing your risk assessment methodology document will look for both — the appetite statement to confirm leadership actually thought about this, and the criteria to confirm it was operationalized consistently.
The Statement of Applicability earns its place at the top of the "ten terms that trip everyone up" list because of a single, persistent misconception: people think it documents the controls they've implemented. It doesn't — or rather, that's only half of it. A complete SoA covers all 93 Annex A controls and, for every single one, states whether it's applicable, whether it's implemented, and — critically — provides a justification either way. An SoA that lists forty controls and is silent on the other fifty-three is not a Statement of Applicability; it's an incomplete inventory, and it will generate a nonconformity almost every time. If you want a working reference to speed up your first draft, PentesterWorld's SoA Template and Risk Register Template are built around this exact requirement — every control gets a row, every row gets a justification.
For a deeper walkthrough of how a risk assessment methodology actually gets built from scratch — scoring matrices, asset inventories, treatment plans — that's a topic large enough for its own guide (a risk assessment methodology deep-dive is on our roadmap; watch for it), but the core vocabulary above is what you need to follow along with any consultant or auditor discussing it today.
Section 3: Annex A and control terms
Annex A of ISO/IEC 27001:2022 is a catalog of 93 controls organized into four themes, and the detailed guidance on how to implement each one lives in the companion standard, ISO/IEC 27002. Understanding the vocabulary that describes how the catalog is structured — themes, attributes, applicability — matters as much as knowing individual control numbers, because it's this structure that lets you reason about coverage and gaps rather than just checking boxes.
Term | Practitioner definition |
|---|---|
Annex A | The normative annex to ISO 27001 listing all 93 information security controls an organization must consider (not necessarily implement) when treating risk |
The four control themes | Organizational (37 controls, numbered 5.1-5.37), People (8 controls, 6.1-6.8), Physical (14 controls, 7.1-7.14), and Technological (34 controls, 8.1-8.34) — the 2022 restructuring that replaced the old 14-domain layout |
Control attributes | Five metadata tags defined in ISO 27002:2022 that let you filter and view the control set from different angles: control type, information security properties, cybersecurity concepts, operational capabilities, and security domains |
Control type | One of the five attributes — classifies a control as preventive (stops an incident before it happens), detective (identifies an incident in progress or after the fact), or corrective (limits or repairs damage after an incident) |
Information security properties | The attribute mapping each control to which leg(s) of the CIA triad it primarily supports — confidentiality, integrity, and/or availability |
Cybersecurity concepts | The attribute aligning each control to one or more of five functions — Identify, Protect, Detect, Respond, Recover — deliberately mirrored to the NIST Cybersecurity Framework's structure to ease cross-framework mapping |
Operational capabilities | The attribute grouping controls by the practical capability they build, such as governance, asset management, physical security, or application security |
Security domains | The attribute grouping controls into four broader domains: governance and ecosystem, protection, defence, and resilience |
Applicability | The determination — recorded in the SoA — of whether a given Annex A control is necessary for a specific organization, based on its risk assessment results and its legal, regulatory, or contractual obligations |
Exclusion (from the SoA) | A documented, justified decision that a particular control is not applicable — exclusions must be reasoned, not simply omitted, and auditors will test the reasoning |
Compensating control | An alternative measure implemented to achieve a similar risk-reduction effect when the standard control can't be applied as written — common where legacy systems or contractual constraints block a textbook implementation |
The four-theme restructuring in the 2022 revision is a common point of confusion for anyone who trained on the 2013 version, which organized controls into fourteen domains (A.5 through A.18). If you're mapping old documentation or a consultant's slide deck that still references "A.9 Access Control" or "A.12 Operations Security," you're looking at 2013-era structure — the direct comparison between the two editions, including a full control mapping, is covered in the ISO 27001:2013 vs ISO 27001:2022 article. For a one-page reference to all 93 controls organized by theme, our Annex A — All 93 Controls at a Glance cheat sheet is built for exactly this kind of quick lookup during an audit prep session.
Control attributes are new enough to the 2022 revision that a lot of practitioners haven't yet built the habit of using them, but they're genuinely useful beyond audit theater. If your organization is trying to demonstrate NIST CSF alignment to a customer, the cybersecurity concepts attribute (Identify/Protect/Detect/Respond/Recover) gives you an instant crosswalk without redoing your entire risk assessment — a topic covered in more depth in ISO 27001 vs Other Security Frameworks. If you're building a security operations dashboard and want to see at a glance which controls are purely preventive versus which ones actually detect active compromise, filtering by control type does that instantly.
A quick worked example of how the four themes actually get used during a gap analysis: when Solandra Freight first mapped its existing security practices against Annex A, its consultant organized the exercise theme by theme rather than control by control, because the themes group naturally around who in the organization needs to be in the room. Organizational controls (5.1-5.37) pulled in legal, HR, and the executive team, because that theme covers policies, supplier relationships, and governance structures. People controls (6.1-6.8) needed HR and line managers, since they cover screening, terms of employment, and disciplinary processes. Physical controls (7.1-7.14) needed facilities and warehouse operations leads, covering everything from secure areas to equipment disposal. Technological controls (8.1-8.34), the largest theme by far at 34 controls, needed IT and engineering, covering everything from endpoint protection to secure coding. Organizing the gap analysis by theme rather than working straight down the numbered list cut Solandra's initial assessment time by roughly a third, because the right people were only pulled into the conversations that actually needed them.
Compensating control isn't formally defined inside ISO 27001 itself the way it is in, say, PCI DSS compensating controls, but the concept is used constantly in practice and auditors generally accept it when it's well-reasoned. A worked example: Solandra Freight's legacy warehouse management system can't support modern password complexity rules because of a vendor-imposed character limit from the early 2000s. Rather than leaving that gap open, Solandra implemented network segmentation isolating the system, restricted access to two named operators, and layered on mandatory MFA at the network boundary. That combination is a compensating control — it doesn't satisfy the letter of the original control, but it demonstrably achieves an equivalent risk reduction, and Solandra documented the reasoning in its risk treatment plan so the SoA entry wasn't just an exclusion with no explanation.
"The biggest myth I have to correct with new control owners is that 'applicable' means 'technically possible for us to do.' Applicability is a risk-driven and legally-driven determination, not a feasibility study. I've seen companies exclude perfectly feasible controls because nobody connected them back to an actual risk in the register — that's the fastest way to earn a nonconformity." — Tomas Reyes, internal audit lead, financial services sector
Section 4: Audit and certification terms
This is the vocabulary that governs the relationship between your organization and the outside world — the certification body, the accreditation system behind it, and the mechanics of how an audit actually proceeds from opening meeting to closing report. It's also, in my experience, the section practitioners least understand before their first certification cycle, because most of it simply isn't covered anywhere in the standard's own text — it's part of the surrounding certification ecosystem defined by ISO/IEC 17021-1 and the accreditation bodies that oversee it. If your organization is also pursuing a SOC 2 Type II report alongside ISO 27001, it's worth knowing upfront that SOC 2 doesn't use "certification" terminology at all — it produces an auditor's opinion in a report, not a certificate — which is a vocabulary trap in its own right when the two programs run in parallel.
Term | Practitioner definition |
|---|---|
Certification body (CB) | The accredited, independent organization that conducts your audits and issues (or withdraws) your ISO 27001 certificate |
Accreditation body (AB) | The national or international authority that accredits certification bodies, confirming they're competent to issue valid certificates — e.g., UKAS in the UK, ANAB in the US |
Stage 1 audit | The first-stage audit focused on documentation review and readiness — checking your ISMS scope, policies, risk assessment, and SoA exist and are coherent before Stage 2 tests whether they actually work |
Stage 2 audit | The second-stage audit testing implementation and operating effectiveness — auditors sample evidence, interview control owners, and verify the ISMS is functioning as documented, not just written down |
Surveillance audit | A shorter annual audit conducted in years one and two of a three-year certification cycle, checking that the ISMS remains effective and that prior nonconformities have been closed — it is not a formality, and it can suspend a certificate |
Recertification audit | The full audit conducted at the end of the three-year cycle (typically in year three) to renew the certificate for another three years |
Audit scope | The specific boundaries — locations, processes, systems — that a given audit will examine, which may be narrower than the full ISMS scope for a single surveillance visit |
Audit criteria | The set of requirements used as the reference point for the audit — typically the ISO 27001 clauses, the organization's own SoA, and its internal policies and procedures |
Evidence (audit evidence) | Records, statements of fact, or other verifiable information relevant to the audit criteria and capable of being verified — the raw material an auditor collects to reach a finding |
Finding | The result of evaluating collected audit evidence against the audit criteria — findings can indicate conformity, nonconformity, or improvement opportunities |
Nonconformity | The non-fulfillment of a requirement — split into major (a systemic failure, an absence of a required process, or something that would likely result in certification failure or an unmanaged risk) and minor (an isolated lapse in an otherwise functioning process) |
Observation | A note an auditor raises that isn't yet a nonconformity but flags a risk area worth monitoring — terminology and formality vary by certification body |
Opportunity for improvement (OFI) | A suggestion the auditor offers for strengthening the ISMS beyond the bare minimum requirement — not a nonconformity, and does not require a formal corrective action, though ignoring good OFIs repeatedly tends to look bad over time |
Corrective action | The documented process of identifying the root cause of a nonconformity, fixing it, and implementing changes to prevent recurrence, required by clause 10.1 |
Root cause analysis | The structured technique (5 Whys, fishbone diagrams, fault tree analysis) used to identify the underlying cause of a nonconformity rather than just patching its symptom |
Internal audit | The organization's own periodic audit of its ISMS, required by clause 9.2, conducted by personnel independent of the area being audited (internal staff or a contracted internal auditor, but not the certification body) |
External audit | An audit conducted by a party outside the organization — most commonly the certification body, but the term can also cover second-party audits conducted by a customer |
Lead auditor | The auditor formally responsible for planning, conducting, and reporting an audit, typically holding a recognized qualification (such as an IRCA-certified ISO 27001 Lead Auditor credential) |
Competence | The clause 7.2 requirement that people doing work affecting information security performance have the necessary education, training, or experience — and that the organization retains evidence of it |
The major versus minor nonconformity distinction is worth its own worked example, because the difference in consequence is dramatic and the classification is not always obvious in the moment. A minor nonconformity might be a single access review that was three weeks late for one system, in an otherwise consistently operating access review process — annoying, correctable, and unlikely to derail certification. A major nonconformity is something like Solandra's risk-owner gap from the cold open: a systemic absence of a required control (documented risk ownership across the SoA), or a nonconformity so significant it calls into question whether the ISMS is capable of achieving its intended outcomes at all. Major nonconformities generally must be corrected — with evidence — before a certificate can be issued or maintained; minor ones typically get a defined window (often 90 days) to remediate, verified at the next audit.
Observation and opportunity for improvement are frequently used almost interchangeably by different certification bodies, and this is one of the few places in this glossary where I'll flag that terminology genuinely varies across CBs rather than being strictly standardized. What doesn't vary is the practical consequence: neither one is a nonconformity, neither one requires a formal corrective action plan, and neither one threatens your certificate. I've watched otherwise sharp ISMS managers spend three stressful weeks and thousands of dollars in unnecessary consultant hours "fixing" an OFI as though it were a major finding — a mistake that costs real money for zero certification benefit.
"The single most common panic I get calls about is a client who received two OFIs and one minor nonconformity, and is treating all three as if the certificate is at risk. It isn't. Read the classification on the report before you mobilize your whole team — that classification is the entire point of the vocabulary." — Sarah Lindqvist, ISMS risk manager, previously led certification for three multinational clients
The Stage 1 versus Stage 2 distinction matters because organizations sometimes treat Stage 1 as a rubber stamp and get blindsided. Stage 1 is a genuine gate — I've seen audits halted at Stage 1 because the scope statement contradicted the risk assessment, or because the SoA was missing justifications for a third of its controls. Passing Stage 1 doesn't guarantee passing Stage 2; it confirms you're ready to be tested, the way a dissertation committee confirming your proposal is coherent doesn't guarantee you'll defend it successfully.
A concrete illustration of how these terms interact across an audit lifecycle: a mid-sized healthcare SaaS company I worked with, Verdant Health Analytics, went into its Stage 2 audit with 61 employees and a scope covering its patient-analytics platform. The lead auditor's evidence sampling turned up a finding: the internal audit schedule showed only one internal audit conducted in the prior twelve months, against a documented internal audit program calling for two. That's a straightforward nonconformity — classified minor, because the underlying internal audit process existed and was broadly functioning, it just hadn't hit its planned frequency. Verdant's corrective action was to conduct root cause analysis (the internal auditor had left the company and the role sat vacant for five months), hire a contracted internal auditor to close the gap, and revise the internal audit program to include a coverage contingency for staff turnover. That correction, with evidence, closed the nonconformity at the next surveillance audit nine months later, and Verdant's certificate was never at risk — because a minor nonconformity, correctly handled, is a normal and expected part of a functioning ISMS, not a crisis.
For teams building or refreshing their own internal audit program, PentesterWorld's Internal Audit Checklist maps directly onto the finding-to-corrective-action lifecycle described above (paired with an internal audit report template for documenting results), and the Internal Audit Interview Question Script is built around the exact kind of pointed, evidence-seeking questions Priya Raman asked Marcus Webb in the opening story. A dedicated deep-dive on running an internal audit program end to end — planning, sampling, interviewing, reporting — is a natural next article for this pillar; until then, this glossary's audit section should get you through your first cycle without needing to guess at terminology mid-interview.
Section 5: Core security concepts
Some vocabulary in an ISMS conversation doesn't come from ISO 27001's own clauses at all — it comes from the broader information security discipline that the standard assumes you already understand. These terms appear constantly in policies, risk assessments, and Annex A control descriptions, and not knowing them fluently is one of the fastest ways to look unprepared in front of an auditor or a client, even if your governance vocabulary is flawless.
Term | Practitioner definition |
|---|---|
CIA triad | The foundational model of confidentiality, integrity, and availability — the three properties nearly every information security control exists to protect, in some combination |
Confidentiality | Ensuring information is accessible only to those authorized to see it — the property most people think of first when they hear "security," but only one-third of the picture |
Integrity | Ensuring information and systems remain accurate, complete, and unaltered except by authorized action — the property that matters most when a single falsified record can cascade into bad decisions |
Availability | Ensuring information and systems are accessible and usable when authorized users need them — the property most directly tested by outages, ransomware, and denial-of-service attacks |
Non-repudiation | The ability to prove that a specific action or event occurred and cannot later be credibly denied by the party who performed it — the property behind digital signatures and detailed audit logging |
Least privilege | The principle that users and systems should be granted only the minimum access necessary to perform their function, and nothing more — one of the most frequently cited justifications in Annex A access control controls |
Defense in depth | The strategy of layering multiple, independent controls so that the failure of any single control doesn't result in a full compromise — the practical antidote to relying on one "silver bullet" defense |
Incident (information security incident) | A single event or series of events with a significant probability of compromising business operations and threatening information security, requiring a formal response |
Event | An occurrence indicating a possible breach of security policy, a failure of controls, or a previously unknown situation — not every event escalates into an incident, but every incident starts as one or more events |
Business continuity | The organization's demonstrated capability to continue delivering products and services at an acceptable, predefined level following a disruptive incident |
Recovery Time Objective (RTO) | The maximum acceptable length of time a system or process can be down before the impact becomes unacceptable to the business |
Recovery Point Objective (RPO) | The maximum acceptable amount of data loss, measured in time, that the organization can tolerate — e.g., an RPO of one hour means backups must be no more than an hour old when restored |
The event versus incident distinction is one I see engineers get wrong constantly, and it matters because it determines whether your incident response process — and its documentation and notification obligations — actually gets triggered. A failed login attempt is an event. A hundred thousand failed login attempts against one account in ten minutes is still, technically, a series of events, but it crosses into incident territory the moment it represents a credible, significant probability of compromise — which is exactly when your incident response plan, not just your monitoring dashboard, needs to activate. Under-classifying an incident as merely "an event we're watching" is how organizations miss regulatory notification windows.
RTO and RPO are business continuity terms rather than ISO 27001-native vocabulary, but they show up constantly in Annex A control discussions (particularly around ICT readiness for business continuity) and in any conversation about backup strategy. A useful mental model: RTO answers "how long can we be down," RPO answers "how much data can we afford to lose." A payments processor might set an RTO of 15 minutes and an RPO of near-zero for its transaction database, while accepting an RTO of 24 hours and an RPO of one day for its internal HR system — because the cost of near-zero RPO everywhere would be disproportionate to the actual risk each system carries.
A short worked example on RTO and RPO in practice: a logistics client of mine, Cascade Distribution, ran a business continuity exercise simulating a ransomware attack against its route-optimization system. The system's documented RTO was four hours; the actual restoration, tested live, took eleven hours because the runbook assumed a network configuration that had changed six months earlier without the disaster recovery documentation being updated. That gap — a documented RTO the organization couldn't actually meet — is exactly the kind of finding an auditor testing business continuity controls looks for, and it's a useful reminder that RTO and RPO are only meaningful if they're periodically tested against reality, not just written down once and filed away. Cascade's corrective action included quarterly recovery drills specifically designed to catch configuration drift before an auditor — or a real incident — found it first.
"Non-repudiation is the property everyone forgets to name but relies on constantly. Every time someone asks me 'can we prove who approved this change,' they're asking a non-repudiation question, even if they've never used the word." — Marcus Webb, CISO, Solandra Freight (yes, the same Marcus from the cold open — he's since become something of an evangelist for getting the vocabulary right)
For a broader treatment of how these foundational security concepts map onto the specific structure of an ISMS — where the CIA triad shows up in risk assessment criteria, where least privilege gets operationalized into access control policy — the Information Security Management System (ISMS): Core Concepts Explained article is the natural next read.
Terms people confuse
Some pairs of terms are close enough in everyday meaning that even experienced practitioners slip between them under pressure. These five contrasts are the ones I get asked to clarify most often — treat this section as your pre-audit sanity check.
Nonconformity vs. observation vs. opportunity for improvement
Aspect | Nonconformity | Observation | Opportunity for Improvement (OFI) |
|---|---|---|---|
What it means | A requirement was not fulfilled | A potential concern noted, not yet a confirmed gap | A suggestion to strengthen something already conforming |
Requires formal corrective action? | Yes, always | Not formally, but often monitored at next audit | No |
Threatens certification? | Major: yes, until resolved. Minor: not immediately, given a remediation window | No | No |
Typical practitioner reaction | Root cause analysis and documented correction | Note it, watch it, address proactively if resources allow | Consider adopting; ignoring repeatedly can look complacent |
Risk appetite vs. risk criteria
Aspect | Risk appetite | Risk criteria |
|---|---|---|
Level | Strategic, leadership-level | Operational, assessor-level |
Form | Qualitative statement of intent | Quantitative or semi-quantitative thresholds |
Example | "We have low appetite for risk to customer data" | "Any risk scored 15+ on our 5x5 matrix requires mandatory treatment" |
Who owns it | Top management / the board | Risk management function, derived from appetite |
Inherent risk vs. residual risk
Aspect | Inherent risk | Residual risk |
|---|---|---|
When measured | Before any controls are applied | After controls are implemented and operating |
What it represents | Raw, theoretical exposure | Real-world exposure the organization actually carries |
What happens to it | Used to prioritize which risks need treatment | Formally accepted (or further treated) by the risk owner |
Control objective vs. control
Aspect | Control objective | Control |
|---|---|---|
Nature | The goal or intended outcome | The specific mechanism or measure |
Example | "Ensure only authorized personnel can access sensitive systems" | Multi-factor authentication, role-based access control, periodic access reviews |
Where it lives | Described at the theme/category level in ISO 27002 | Individually numbered and implemented (e.g., control 8.5) |
Internal audit vs. external audit vs. surveillance audit
Aspect | Internal audit | External (certification) audit | Surveillance audit |
|---|---|---|---|
Conducted by | The organization itself (staff or contracted auditor) | The certification body | The certification body |
Frequency | Per internal audit program, typically annual across the ISMS scope | Stage 1 and Stage 2 at initial certification, recertification every 3 years | Annually, in years one and two of the three-year cycle |
Purpose | Self-check before the CB ever arrives | Determine whether to grant/renew certification | Confirm the ISMS remains effective between full audits |
Can it revoke a certificate? | No | Yes (at the point of certification decision) | Yes, if significant nonconformities are found and not resolved |
"I tell every client the same thing before their first surveillance audit: it is not a lighter Stage 2. I have suspended a certificate off the back of a surveillance visit because a major nonconformity from the prior year was never actually closed — just marked closed on paper." — Priya Raman, lead auditor
The vocabulary is the shortcut, not the obstacle
Marcus Webb's story didn't end with the lost contract. Solandra Freight recertified eight months later, this time with a documented risk owner for every SoA exclusion and a CISO who could trace any control on the floor back through the risk it treated and the asset it protected — the exact fluency Priya Raman told me she looks for in the first hour of any audit. Solandra won back a version of that retail contract eleven months after the failed Stage 2, at a slightly reduced first-year value, because the retailer's security team had, by then, moved on to a different vendor for the largest piece of the work.
That's the real cost of getting the vocabulary wrong: not embarrassment, but sequencing. Every one of the sixty-plus terms in this glossary exists because someone, somewhere, needed a precise way to describe a decision, an accountability, or a piece of evidence — and precision under audit pressure is what separates an ISMS that's merely documented from one that's demonstrably alive. Compliance done well isn't a tax on the business; it's increasingly the credential that opens the door to the contract, the insurer's better rate, and the enterprise customer who won't sign without it. The vocabulary in this glossary is how you walk through that door fluently instead of stumbling through it the way Marcus did on his first attempt.
If you're building out your ISMS documentation and want the reference material to match this vocabulary term for term, PentesterWorld's ISO 27001 Glossary of Terms asset is designed as a companion desk reference to keep alongside your risk register and SoA — and if you'd rather have an experienced second set of eyes stress-test your Statement of Applicability, your risk ownership assignments, or your readiness for Stage 1 before an auditor finds the gaps first, PentesterWorld's penetration testing and compliance readiness teams work with organizations at exactly this stage, translating standard language into a defensible, audit-ready ISMS.