# ISMS Glossary: [Organization name]

> A plain-language glossary of 147 terms used when building,
> running, auditing and certifying an information security management
> system (ISMS) under ISO/IEC 27001:2022 + Amd 1:2024. Every definition is
> written in original words for learners and practitioners, with the clause
> or Annex A control where the term matters and the library template that
> puts it to work. It is not a copy of the terms in ISO/IEC 27000:2026; for
> the normative terms, read the official standard. It supports awareness
> and competence (clauses 7.2 and 7.3) and consistent use of terms across
> ISMS documents (clause 7.5). Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Use it when onboarding anyone to the ISMS, when writing policies (so the
  same word means the same thing everywhere), and when preparing staff for
  audit interviews.
- Fill the Document control table first, then section 11 (your own
  organisation's terms, such as what you call a "risk owner" or which
  committee acts as "top management"). Sections 3 to 10 can be used as they
  are.
- Main pitfall: copying definitions from the standard into your documents.
  ISO text is copyrighted, and the ISO/IEC 27000:2026 terms clause is much
  shorter than the 2018 edition. Use your own definitions that are
  consistent with the standard, and refer to ISO/IEC 27000 for the official
  ones.
- Second pitfall: one word, two meanings. "Incident" in the service desk
  and "information security incident" in the ISMS are not the same thing.
  Record the difference in section 11.
- Related templates: `isms/isms-learning-path`,
  `isms/iso-27001-clauses-explained`, `isms/isms-self-test`,
  `isms/iso-27000-family-map`, `isms/isms-manual`.
-->

## Document control

<!-- Guidance: Keep the glossary controlled if your policies refer to it for definitions. Then a change to a definition is a change to every document that uses the term, and it needs the same review. -->

| Field | Value |
|---|---|
| Document ID | LRN-ISMS-02 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ciso], [@policy-owner] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024; ISO/IEC 27000:2026 (terms referenced, not reproduced) |
| Number of terms | [Count after you add section 11 terms] |
| Referenced by | DOC-ISMS-001, DOC-ISMS-005, DOC-ISMS-008 |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| CISO or security lead | [@ciso] | [Approved / Approved with changes] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2026-11-01 | [@isms-manager] | First glossary, sections 3 to 9 |
| 1.1 *(Example)* | YYYY-MM-DD | [@isms-manager] | Organisation terms added in section 11 after the policy review |

## Contents

<!-- Guidance: Terms are grouped by topic so a learner can read one area at a time. Section 10 lists abbreviations. Section 11 is yours. -->

1. Purpose and use
2. Conventions
3. Core management system terms
4. Risk terms
5. Control and Annex A terms
6. Operations, incident and continuity terms
7. Measurement, audit and improvement terms
8. Certification terms
9. Privacy, cloud and related family terms
10. Abbreviations
11. Organisation-specific terms
12. Size tiers: how the same terms map to different organisations
13. Records and evidence
14. References

## 1. Purpose and use

<!-- Guidance: Say who must use the glossary and for what. An auditor will not audit a glossary, but inconsistent terms across documents (for example three different meanings of "asset owner") often lead to findings. -->

The glossary has three uses:

1. **Learning.** Module M0 and M1 of `isms/isms-learning-path` use it as
   the vocabulary reference. Section 3 holds the core terms to learn first.
2. **Consistency.** Policies, procedures and records use the terms as
   defined here. When a document needs a narrower meaning, it says so.
3. **Audit readiness.** Staff who can explain terms such as "risk owner",
   "residual risk" or "nonconformity" in their own words do better in audit
   interviews than staff who recite a definition.

The glossary does not replace ISO/IEC 27000:2026, which holds the
normative terms for the family. Where this glossary and the standard
differ in nuance, the standard prevails for audit purposes.

## 2. Conventions

<!-- Guidance: Explain how to read the tables. Keep the "Where it matters" column accurate: a wrong clause number teaches a wrong habit. -->

- **Definitions are original.** They explain the idea in plain words and
  sometimes add a practical example. They are not quotations.
- **Where it matters** gives the ISO/IEC 27001:2022 clause or Annex A
  control where the term is most relevant. "A.5.15" means Annex A control
  5.15. Clause numbers refer to ISO/IEC 27001:2022 + Amd 1:2024 unless
  another standard is named.
- **See also** gives the library template, by `category/slug`, that uses
  the term in practice.
- **Risk scale.** Terms about risk levels use the library scale:
  likelihood 1 to 5 times impact 1 to 5, score 1 to 25, bands Low 1-4,
  Medium 5-9, High 10-16, Critical 17 to 25 (in practice 20 and 25)
  (`compliance/risk-methodology`).

## 3. Core management system terms

<!-- Guidance: Learn these first. Every ISMS document uses them. Pitfall: "scope" and "context" are often confused; context is what affects you, scope is what the ISMS covers. -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Information security | Keeping information confidential, accurate and complete, and available to the right people when needed | Whole standard | `compliance/information-security-policy` |
| Confidentiality | Information is kept away from anyone, or any system, that has no permission to read it | 6.1.2, A.5.12 | `data/data-classification-policy` |
| Integrity | Information can be trusted: nothing has been altered, lost or added without permission, and changes can be traced | 6.1.2, A.8.32 | `ops/change-request` |
| Availability | The people and systems that need information or a service can reach it and use it at the time they need it | 6.1.2, A.8.13, A.8.14 | `isms/backup-policy` |
| Information security management system (ISMS) | The set of policies, processes, roles, records and controls an organisation uses to manage information security risk in a planned, checked and improving way | 4.4 | `isms/isms-manual` |
| Management system | The way an organisation runs one area of work (quality, continuity, security) in a deliberate cycle: it sets aims and rules, does the work, checks results and adjusts | 4.4 | `compliance/iso-map` |
| Harmonized structure | The common clause layout (4 to 10) that ISO management system standards share, which makes integration easier | Clauses 4 to 10 | `isms/integrated-management-27013` |
| Context of the organization | The internal and external conditions that affect what the ISMS must achieve and how | 4.1 | `isms/isms-context-interested-parties` |
| Issue (internal or external) | A condition, trend or fact inside or outside the organisation that can help or hinder the ISMS, such as a new regulation or staff turnover | 4.1 | `isms/isms-context-interested-parties` |
| Climate change issue | A decision, required since Amendment 1:2024, on whether climate change is relevant to the ISMS, for example through data centre resilience or supply chains | 4.1, 4.2 note | `isms/isms-context-interested-parties` |
| Interested party | Anyone with a stake in how the organisation protects information, because they can influence it or feel its results, such as customers, regulators or staff (also called a stakeholder) | 4.2 | `isms/isms-context-interested-parties` |
| Requirement | Something the organisation must or is expected to do, whether written down (a contract clause, a law) or simply taken for granted by customers and staff | 4.2 | `compliance/legal-register` |
| Scope | The boundary of the ISMS: which organisational units, locations, services, information and technology it covers, and the interfaces to what lies outside | 4.3 | `compliance/ms-scope` |
| Process | A repeatable way of working with a start, an end, an owner and something useful produced, such as access review or internal audit; the ISMS is a group of connected processes | 4.4 | `isms/isms-process-map` |
| Top management | The most senior leaders of the organisation, or of the part in scope, who make the final decisions and answer for the ISMS (for example the CEO and executive team) | 5.1 | `isms/isms-steering-committee-charter` |
| Information security policy | The top-level statement, approved by top management, that sets direction, objectives or how to set them, and the commitments to meet requirements and improve | 5.2 | `compliance/information-security-policy` |
| Topic-specific policy | A policy on one subject, such as access control or remote working, that sits under the top-level policy | A.5.1 | `isms/isms-policy-framework` |
| Role, responsibility and authority | Who does what (role), what they must achieve (responsibility) and what they may decide (authority) | 5.3 | `isms/isms-roles-raci` |
| Objective | A measurable result the ISMS aims for, such as "95% of staff complete training by June" | 6.2 | `compliance/objectives-register` |
| Documented information | The written or stored material the ISMS depends on, in any format (file, wiki page, ticket, recording): documents that describe how things are done and records that prove what happened | 7.5 | `isms/isms-documented-information-register` |
| Document | Documented information that describes intent or method (policy, procedure, standard); it is revised over time | 7.5.2 | `compliance/controlled-document` |
| Record | Documented information that proves something happened (log, signed form, minutes); it should not be changed after the fact | 7.5.3 | `isms/control-evidence-matrix` |
| Competence | Being able to do a role well in practice, not just knowing about it; shown by education, training or experience | 7.2 | `isms/isms-competence-training-matrix` |
| Awareness | Knowing the policy, how you contribute to the ISMS and what happens if you do not follow it | 7.3 | `security/security-awareness-program` |
| Externally provided process | A process, product or service that someone outside the organisation delivers and that matters to the ISMS, such as hosting or payroll | 8.1 | `isms/supplier-register` |
| Effectiveness | Whether something actually works: the plan was carried out and it delivered the result it was meant to deliver | 9.1, 9.3 | `isms/isms-performance-report` |
| Conformity | Doing what is required, either by the standard or by the organisation's own ISMS rules | 9.2 | `isms/isms-internal-audit-checklist` |
| Continual improvement | The ongoing habit of making the ISMS fit the organisation better and work better, step by step, not only after something goes wrong | 10.1 | `isms/continual-improvement-register` |

## 4. Risk terms

<!-- Guidance: Risk terms cause the most confusion at audits. Make sure risk owners can explain "residual risk" and "risk acceptance" for their own risks. -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Risk | Something that might or might not happen and would change what the organisation is trying to achieve; in security, the chance that information is harmed and how bad that would be | 6.1 | `compliance/risk-methodology` |
| Risks and opportunities | ISMS-level things that could stop or help the ISMS reaching its outcomes, broader than risks to assets | 6.1.1 | `isms/isms-context-interested-parties` |
| Opportunity | A situation that could improve security or the ISMS, such as a platform migration that allows better logging | 6.1.1 | `isms/continual-improvement-register` |
| Information security risk | A risk of losing confidentiality, integrity or availability of information within the scope | 6.1.2 | `compliance/risk-register` |
| Risk assessment | The full exercise of spotting risks, sizing them and ranking them against the criteria; the three steps below | 6.1.2, 8.2 | `isms/isms-risk-assessment-report` |
| Risk identification | Listing what could go wrong: the scenario, what it affects, its cause and how it would happen | 6.1.2 c | `isms/isms-threat-vulnerability-catalogue` |
| Risk analysis | Working out how likely a risk is and how serious its consequences would be, to set a risk level | 6.1.2 d | `compliance/risk-methodology` |
| Risk evaluation | Checking each scored risk against the acceptance rules to see which ones need action and which come first | 6.1.2 e | `compliance/risk-methodology` |
| Risk criteria | The rules for assessing risk: scales, how to combine them, and when a risk is acceptable | 6.1.2 a | `isms/isms-risk-appetite-criteria` |
| Risk acceptance criteria | The part of the risk criteria that says which risk levels may be accepted and by whom | 6.1.2 a | `isms/isms-risk-appetite-criteria` |
| Risk appetite | Top management's stated comfort level with risk: where it will take chances to reach its goals and where it wants risk kept low | 6.1.2, 5.1 | `isms/isms-risk-appetite-criteria` |
| Risk owner | The named person who answers for a risk and can make decisions about it, including approving its treatment and accepting what remains | 6.1.2 c, 6.1.3 f | `isms/isms-roles-raci` |
| Asset | Something the organisation relies on and would suffer from losing or having damaged: information, systems, people, sites, services | A.5.9 | `compliance/asset-inventory` |
| Asset owner | The person accountable for an asset's protection throughout its life; often not the same person as the risk owner | A.5.9 | `compliance/asset-inventory` |
| Threat | Whoever or whatever could cause harm to information, such as a ransomware gang, a careless insider or a flood | 6.1.2 | `isms/isms-threat-vulnerability-catalogue` |
| Vulnerability | A gap or flaw in a system, process or control that makes harm easier, such as an unpatched server or a shared password | 6.1.2, A.8.8 | `isms/vulnerability-remediation-tracker` |
| Likelihood | How probable it is that a risk happens in a given period; scored 1 to 5 in the library scale | 6.1.2 d | `compliance/risk-methodology` |
| Consequence (impact) | How serious the outcome would be if the risk happened; scored 1 to 5 in the library scale | 6.1.2 d | `compliance/business-impact-analysis` |
| Level of risk (risk score) | The number that ranks a risk; in the library scale likelihood times impact, so likelihood 3 and impact 4 give 12, which is High | 6.1.2 d | `compliance/risk-register` |
| Inherent risk | The risk level before taking current controls into account; not all methods use it | 6.1.2 | `compliance/risk-methodology` |
| Residual risk | What is left of a risk once the chosen treatment is in place; risk owners must accept it | 6.1.3 f | `isms/isms-risk-acceptance-record` |
| Risk treatment | Deciding what to do about a risk and then doing it | 6.1.3, 8.3 | `compliance/risk-treatment-plan` |
| Risk treatment options | The main choices: reduce the risk with controls, retain it, avoid it by stopping the activity, or share it (for example with insurance or a supplier) | 6.1.3 a | `compliance/risk-treatment-plan` |
| Risk treatment plan | The plan that says which treatment actions happen, who does them, by when and with what resources | 6.1.3 e | `compliance/risk-treatment-plan` |
| Risk acceptance | A documented decision by the right person to keep a risk at its current level | 6.1.3 f | `isms/isms-risk-acceptance-record` |
| Risk register | The list of identified risks with their analysis, owner, treatment and status | 6.1.2, 8.2 | `compliance/risk-register` |
| Event-based approach | Identifying risks from scenarios of what could happen (events and their sources), as described in ISO/IEC 27005:2022 | 6.1.2 | `compliance/risk-methodology` |
| Asset-based approach | Identifying risks by going through assets, their threats and vulnerabilities, as described in ISO/IEC 27005:2022 | 6.1.2 | `compliance/asset-inventory` |
| Risk exception | A time-limited, approved deviation from a policy or control, treated as an accepted risk with a review date | 6.1.3 f | `security/security-exception-request` |

## 5. Control and Annex A terms

<!-- Guidance: Learn the difference between Annex A (the reference list), the SoA (your decisions about that list) and ISO/IEC 27002 (guidance on each control). -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Control | Anything put in place to make a risk smaller or easier to live with, such as a policy, a procedure, a technical setting or a physical barrier | 6.1.3 | `compliance/statement-of-applicability` |
| Annex A | The reference list of 93 information security controls in ISO/IEC 27001:2022, grouped in four themes, used to check that no necessary control is missed | 6.1.3 c | `isms/annex-a-organizational-controls-guide` |
| Control theme | One of the four Annex A groups: organizational (A.5, 37 controls), people (A.6, 8), physical (A.7, 14), technological (A.8, 34) | Annex A | `isms/annex-a-technological-controls-guide` |
| Statement of Applicability (SoA) | The record of which controls are necessary, why each is included, whether each is implemented, and why any Annex A control is excluded | 6.1.3 d | `compliance/statement-of-applicability` |
| Justification for exclusion | The reason an Annex A control is not needed, tied to the risk assessment or to the scope, not to convenience | 6.1.3 d | `compliance/statement-of-applicability` |
| Control attribute | A tag in ISO/IEC 27002:2022 used to group and filter controls; the five attributes are control type, information security properties, cybersecurity concepts, operational capabilities and security domains | ISO/IEC 27002:2022 | `isms/control-framework-crosswalk` |
| Preventive, detective, corrective | The control type attribute: stops an event, spots it, or limits and repairs its effects | ISO/IEC 27002:2022 | `isms/annex-a-technological-controls-guide` |
| Cybersecurity concepts | The attribute that maps a control to Identify, Protect, Detect, Respond or Recover (the five functions of NIST CSF 1.1; CSF 2.0 added Govern, which is not a 27002 value), which helps link ISO/IEC 27001 to NIST CSF style models | ISO/IEC 27002:2022 | `compliance/nist-csf` |
| Control owner | The person accountable for a control operating as designed and for producing its evidence | 5.3, 8.1 | `isms/control-evidence-matrix` |
| Compensating control | A different control used when the expected one cannot be applied, giving a similar reduction in risk | 6.1.3 | `security/security-exception-request` |
| Defence in depth | Layering several independent controls so one failure does not expose the information | 6.1.3 | `security/zero-trust-architecture` |
| Least privilege | Giving each person or system only the access needed for its task, and no more | A.5.15, A.8.2 | `isms/access-control-policy` |
| Need to know | Access to information is limited to people whose work requires it | A.5.15, A.8.3 | `isms/access-control-policy` |
| Segregation of duties | Splitting conflicting tasks between different people so one person cannot misuse or hide a misuse alone | A.5.3 | `isms/isms-roles-raci` |
| Information classification | Sorting information into levels (for example Public, Internal, Confidential) based on its sensitivity and value | A.5.12 | `data/data-classification-policy` |
| Labelling | Marking information with its classification so people and systems handle it correctly | A.5.13 | `isms/information-labelling-handling-procedure` |
| Threat intelligence | Collecting and analysing information about threats so decisions and controls stay current; new in 2022 | A.5.7 | `isms/threat-intelligence-procedure` |
| Configuration management | Defining, applying and monitoring secure settings for hardware, software, services and networks; new in 2022 | A.8.9 | `isms/secure-configuration-baseline` |
| Information deletion | Removing information when it is no longer needed, in a way that prevents recovery where required; new in 2022 | A.8.10 | `data/data-retention-deletion-standard` |
| Data masking | Hiding or replacing parts of data (for example with pseudonyms or partial values) to limit exposure; new in 2022 | A.8.11 | `isms/data-masking-dlp-standard` |
| Data leakage prevention | Measures that detect and stop sensitive information leaving through unauthorised routes; new in 2022 | A.8.12 | `isms/data-masking-dlp-standard` |
| Secure development life cycle | Building security into every phase of software and system development, from requirements to retirement | A.8.25 | `isms/secure-development-policy` |
| Secure coding | Writing code that follows safe practices and avoids known weakness patterns; new in 2022 | A.8.28 | `security/secure-coding-standard` |
| Cryptography | Using encryption, hashing and signatures, with managed keys, to protect information | A.8.24 | `security/cryptography-standard` |
| Privileged access | Access that can change systems or security settings, such as administrator accounts, which needs tighter control | A.8.2 | `security/privileged-access-standard` |

## 6. Operations, incident and continuity terms

<!-- Guidance: These terms appear in daily operation and in incident handling. Make sure staff know the difference between an event and an incident, and know where to report either. -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Information security event | Anything noticed that might point to a security problem, such as a suspicious e-mail or an unusual login; most turn out to be harmless | A.6.8, A.5.25 | `isms/security-event-reporting-procedure` |
| Information security incident | A security problem confirmed by triage as real or likely harm to the organisation or its information, so the response process starts | A.5.24 to A.5.26 | `compliance/incident-response-plan` |
| Incident management | The planned way of detecting, assessing, responding to and learning from incidents | A.5.24 to A.5.27 | `isms/incident-register` |
| Post-incident review | A structured review after an incident to find causes and improvements, without blame | A.5.27 | `isms/post-incident-review` |
| Digital evidence | Data collected in a way that keeps it reliable for disciplinary, legal or regulatory use | A.5.28 | `security/forensic-evidence-record` |
| Personal data breach | A security incident that affects personal data; laws such as the GDPR may set notification duties | A.5.34 | `compliance/personal-data-breach-assessment` |
| Business continuity | The ability to keep delivering key services at an acceptable level during and after a disruption; Annex A covers keeping security during disruption and ICT readiness | A.5.29, A.5.30 | `compliance/business-continuity` |
| ICT readiness for business continuity | Making sure technology can be restored in line with continuity needs; new in 2022 | A.5.30 | `isms/ict-readiness-business-continuity-plan` |
| Recovery time objective (RTO) | The target time to restore a service or system after a disruption | A.5.30 | `compliance/business-impact-analysis` |
| Recovery point objective (RPO) | The maximum acceptable amount of data loss, measured in time before the disruption | A.8.13 | `isms/backup-policy` |
| Backup | A copy of information kept so it can be restored after loss or damage, tested regularly | A.8.13 | `isms/backup-restore-test-log` |
| Change management | Controlling changes to systems and services so they are assessed, approved, tested and recorded | A.8.32 | `ops/change-enablement-policy` |
| Vulnerability management | Finding, rating and fixing technical weaknesses within set timeframes | A.8.8 | `security/vulnerability-management-policy` |
| Logging | Recording events such as logins, errors and administrator actions so they can be reviewed | A.8.15 | `security/security-logging-standard` |
| Monitoring activities | Watching networks, systems and applications for unusual behaviour and acting on it; new in 2022 | A.8.16 | `isms/security-monitoring-procedure` |
| Supplier | An organisation that provides products or services, from cloud hosting to cleaning, that may affect security | A.5.19 to A.5.22 | `isms/supplier-register` |
| ICT supply chain | The chain of suppliers and their suppliers behind the technology you use, including software components | A.5.21 | `security/supply-chain-security` |
| Cloud service | A service delivered over a network from shared, configurable resources; its security is shared between provider and customer; new control in 2022 | A.5.23 | `isms/cloud-services-security-policy` |
| Shared responsibility | The split of security duties between a cloud provider and its customer, which differs by service model | A.5.23 | `isms/cloud-services-security-policy` |
| Remote working | Working from outside the organisation's premises, with controls for devices, networks and surroundings | A.6.7 | `isms/remote-working-policy` |
| Secure area | A physical area with extra protection because of what it holds, such as a server room | A.7.1 to A.7.6 | `isms/physical-security-policy` |

## 7. Measurement, audit and improvement terms

<!-- Guidance: Internal auditors and the ISMS manager must use these terms precisely. A finding called a "nonconformity" when it is really an observation creates unnecessary work. -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Monitoring | Keeping an eye on how a process, control or system is doing, often continuously or at short intervals | 9.1 | `isms/security-monitoring-procedure` |
| Measurement | Putting a number on something, such as a percentage or a count, using a defined method | 9.1 | `isms/isms-measurement-programme` |
| Measure (metric, indicator) | A defined value with a formula, data source, frequency, target and owner | 9.1 | `isms/isms-measurement-programme` |
| Analysis and evaluation | Interpreting measurement results to judge performance and decide actions | 9.1 | `isms/isms-performance-report` |
| Audit | A planned, impartial and recorded examination that gathers evidence and judges it against agreed rules | 9.2 | `compliance/internal-audit-program` |
| Internal audit | An audit the organisation runs on its own ISMS (or pays an independent party to run) to check conformity and effectiveness | 9.2 | `isms/isms-internal-audit-report` |
| Audit programme | The multi-year or annual schedule of audits: what is audited, when, how and by whom, weighted by importance and previous results | 9.2.2 | `compliance/internal-audit-program` |
| Audit criteria | What the audit compares evidence against: the standard, policies, contracts, laws | 9.2.2 b | `isms/isms-internal-audit-checklist` |
| Audit evidence | What the auditor sees, reads or hears and can check, such as a log, a signed approval or an interview answer | 9.2 | `isms/stage-2-audit-evidence-index` |
| Audit finding | The auditor's conclusion on a point: conformity, nonconformity or an opportunity for improvement | 9.2 | `isms/audit-findings-register` |
| Objectivity and impartiality | Auditors judge evidence fairly and do not audit their own work | 9.2.2 c | `compliance/internal-audit-program` |
| Nonconformity | A gap where something required is not done, whether required by the standard or by the organisation's own ISMS | 10.2 | `compliance/capa-nonconformity` |
| Correction | Immediate action to fix a specific nonconformity, such as removing one leaver's account | 10.2 a | `compliance/capa-nonconformity` |
| Corrective action | A fix aimed at why the problem happened, so the same gap stays closed, such as automating account removal | 10.2 b, c | `compliance/capa-nonconformity` |
| Root cause | The underlying reason a problem happened, found by asking why until the answer is something you can change | 10.2 b | `isms/post-incident-review` |
| Effectiveness review | Checking, after time has passed, that a corrective action really prevented recurrence | 10.2 d | `isms/audit-findings-register` |
| Opportunity for improvement | A point where the ISMS meets requirements but could work better; recorded but not a nonconformity | 9.2, 10.1 | `isms/continual-improvement-register` |
| Management review | Top management's planned review of the ISMS, covering set inputs and leading to decisions on improvement and change | 9.3 | `compliance/management-review` |

## 8. Certification terms

<!-- Guidance: These terms come from ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024, which bind certification bodies, not you. Learn them so you understand what the certification body will do and why. -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Certification | Independent confirmation by a certification body that a management system meets a standard, shown by a certificate | ISO/IEC 17021-1:2015 | `isms/certification-audit-explained` |
| Certification body (CB) | An organisation that audits and certifies management systems | ISO/IEC 17021-1:2015 | `isms/certification-body-selection` |
| Accreditation body | An organisation that checks that certification bodies are competent and impartial | ISO/IEC 17021-1:2015 | `isms/certification-body-selection` |
| Accredited certification | Certification issued by a certification body accredited for that standard, ideally by an accreditation body that is a signatory of the Global ACI MRA (formerly the IAF MLA); check the IAF CertSearch database | ISO/IEC 27006-1:2024 | `isms/certification-body-selection` |
| Stage 1 audit | The first part of the initial audit: the CB reviews documents, readiness and scope, and plans Stage 2 | ISO/IEC 17021-1:2015 | `isms/stage-1-readiness-pack` |
| Stage 2 audit | The second part of the initial audit: the CB checks that the ISMS is implemented and effective | ISO/IEC 17021-1:2015 | `isms/stage-2-audit-evidence-index` |
| Major nonconformity | A serious gap, such as a required process missing or failing across the board, that makes the auditor doubt the ISMS can deliver what it should; the CB decides the grading | ISO/IEC 17021-1:2015 | `isms/certification-findings-action-plan` |
| Minor nonconformity | A real but contained gap, such as one missed review, that does not on its own put the ISMS's results in doubt; the CB decides the grading | ISO/IEC 17021-1:2015 | `isms/certification-findings-action-plan` |
| Certification decision | The CB's decision to grant, maintain, renew or withdraw a certificate, made by people who did not conduct the audit | ISO/IEC 17021-1:2015 | `isms/certification-audit-explained` |
| Certification cycle | The three-year life of a certificate: initial audit, surveillance audits in the following years, recertification before expiry | ISO/IEC 17021-1:2015 | `isms/certification-cycle-plan` |
| Surveillance audit | An audit at least once each calendar year (except recertification years) to confirm the ISMS still works; the first is due no later than 12 months after the certification decision | ISO/IEC 17021-1:2015 | `isms/surveillance-readiness-health-check` |
| Recertification audit | The audit, planned and completed before the certificate expires, that renews the certificate for another cycle | ISO/IEC 17021-1:2015 | `isms/certification-cycle-plan` |
| Audit time | The number of auditor days the CB plans, set from ISO/IEC 27006-1 using the number of people doing work under the organisation's control and complexity factors | ISO/IEC 27006-1:2024 | `isms/certification-body-selection` |
| Multi-site sampling | Rules that let a CB audit a sample of similar sites instead of every site, under ISO/IEC 27006-1 and IAF MD 1:2023, now re-issued by Global ACI as Global ACI-TECH-3-001 (check the current issue) | ISO/IEC 27006-1:2024 | `isms/scope-extension-multisite-plan` |
| Scope extension | Adding sites, services or units to an existing certificate, usually at a surveillance audit or a special audit | ISO/IEC 17021-1:2015 | `isms/scope-extension-multisite-plan` |
| Certification mark | The logo a CB lets certified organisations use (and any accreditation symbol, only under the accreditation body's rules), under strict rules (never on products as if they were certified) | ISO/IEC 17021-1:2015 | `isms/certification-mark-usage` |
| Transition | The period for moving certificates to a new edition; certificates to ISO/IEC 27001:2013 expired at the end of the transition, 2025-10-31 | ISO/IEC 27001:2022 | `isms/certification-cycle-plan` |

## 9. Privacy, cloud and related family terms

<!-- Guidance: These terms appear when the ISMS meets privacy, cloud or AI management. Keep them short here and follow the links for detail. -->

| Term | Plain-language meaning | Where it matters | See also |
|---|---|---|---|
| Personally identifiable information (PII) | Information that can identify a person directly or indirectly; many laws call it personal data | A.5.34 | `compliance/gdpr-ropa` |
| PII controller | The organisation that decides why and how PII is processed | A.5.34, ISO/IEC 27701:2025 | `isms/pims-27701-scope-roles` |
| PII processor | An organisation that handles PII for a controller's purposes and as the controller directs, such as a SaaS provider | A.5.34, ISO/IEC 27701:2025 | `isms/cloud-pii-27018-processor` |
| Privacy information management system (PIMS) | A management system for privacy; ISO/IEC 27701:2025 is now a stand-alone, certifiable standard | ISO/IEC 27701:2025 | `isms/pims-27701-statement-of-applicability` |
| Cloud service provider | The party that makes cloud services available; ISO/IEC 27017:2026 gives cloud-specific control guidance | A.5.23 | `isms/cloud-27017-controls` |
| Cloud service customer | The party that uses cloud services and keeps responsibility for its own configuration and data | A.5.23 | `isms/cloud-services-security-policy` |
| Integrated management system | One management system that meets several standards (for example ISO 9001, ISO 22301, ISO/IEC 27001) with shared processes | Clauses 4 to 10 | `isms/integrated-management-27013` |
| AI management system (AIMS) | A management system for the responsible development or use of AI under ISO/IEC 42001:2023 | ISO/IEC 42001:2023 | `isms/iso-27001-42001-integrated-soa` |
| Operational technology (OT) | Systems that monitor or control physical processes, such as plant control systems, with different availability and safety priorities from IT | 4.3, A.8.20 | `isms/energy-27019-controls` |

## 10. Abbreviations

<!-- Guidance: List abbreviations used across your ISMS documents. Pitfall: an abbreviation used in a policy that staff do not recognise. -->

| Abbreviation | Meaning |
|---|---|
| AIMS | AI management system (ISO/IEC 42001) |
| BCMS | Business continuity management system (ISO 22301) |
| CAPA | Corrective and preventive action, used here for nonconformity and corrective action records |
| CB | Certification body |
| CIA | Confidentiality, integrity, availability |
| DLP | Data leakage prevention |
| EDR | Endpoint detection and response |
| Global ACI | Global Accreditation Cooperation Incorporated, which replaced IAF and ILAC on 2026-01-01 |
| Global ACI MRA | Global ACI recognition arrangement for accreditation bodies (formerly the IAF MLA) |
| IAF | International Accreditation Forum (merged into Global ACI on 2026-01-01) |
| IAF MD | IAF mandatory document, being re-issued as Global ACI technical documents |
| IAF MLA | IAF multilateral recognition arrangement, now the Global ACI MRA |
| ISMS | Information security management system |
| KPI | Key performance indicator |
| MDM | Mobile device management |
| MFA | Multi-factor authentication |
| NC | Nonconformity |
| OFI | Opportunity for improvement |
| OT | Operational technology |
| PII | Personally identifiable information |
| PIMS | Privacy information management system (ISO/IEC 27701) |
| RACI | Responsible, accountable, consulted, informed |
| RPO | Recovery point objective |
| RTO | Recovery time objective |
| RTP | Risk treatment plan |
| SIEM | Security information and event management |
| SoA | Statement of Applicability |

## 11. Organisation-specific terms

<!-- Guidance: Record the words your organisation uses and how they map to ISMS terms. This avoids audit confusion, for example when the "Executive Leadership Team" is top management. Rows marked Example show the format. -->

| Term used here | Maps to ISMS term | Meaning in our organisation | Used in |
|---|---|---|---|
| Executive Leadership Team *(Example)* | Top management | CEO, CFO, CTO and COO acting together for the whole company | DOC-ISMS-001, DOC-ISMS-085 |
| Service owner *(Example)* | Risk owner and asset owner | Manager accountable for a customer-facing service, its risks and its assets | DOC-ISMS-016, DOC-ISMS-012 |
| Security ticket *(Example)* | Information security event | Any report raised through the security queue, before triage decides whether it is an incident | DOC-ISMS-023 |
| Restricted *(Example)* | Highest classification level | Customer health data and keys; only named roles may access it | `data/data-classification-policy` |
| [Local term] | [ISMS term] | [meaning] | [documents] |

## 12. Size tiers: how the same terms map to different organisations

<!-- Guidance: The terms do not change with size, but who fills each role does. Use the library's fictional settings as a guide. -->

The library's working tiers are small (under 50 people), medium (50 to
500) and large or multi-site (over 500 or several sites).

| Term | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Top management | CEO and CTO | Executive team, with a security steering committee | Group board and executive committee; site directors for site matters |
| ISMS manager | Head of Engineering Operations, 0.5 FTE | Full-time ISMS manager | CISO, with a 14-person security office |
| Risk owner | Founders and the two engineering leads | Service and department heads | Group function heads and site directors |
| Control owner | Often the same person for several controls | Named per control, supported by a 3-person security team | Named per control and per site, with group standards |
| Internal audit | Independent external auditor engaged for the audit | Two trained auditors from the quality team | Audit pool across sites, coordinated with ISO 9001 and ISO 22301 audits |
| Interested parties | Customers, the cloud provider, investors, staff | Hospitals, regulators, patients through the hospitals, staff | Customers, regulators in 4 countries, workers' representatives, insurers |
| Scope | Whole company and platform | Software, managed service, two offices, colocation suite | Phased by site, starting with HQ and the data centre |

## 13. Records and evidence

<!-- Guidance: A glossary produces few records, but its use and control can be shown. Link it to the evidence matrix under clause 7.5 and 7.3. -->

| Record | Shows | Kept by | Where | Retention *(Example)* |
|---|---|---|---|---|
| Approved glossary versions | Terms are controlled and consistent across documents (7.5) | ISMS manager | [Document system] | Current plus previous 3 versions |
| Policy reviews that checked terms | Documents use the glossary consistently | Policy owners | [Review records] | 3 years |
| Awareness material using the glossary | Staff learned key terms (7.3) | ISMS manager | [Learning system] | 3 years |
| Self-test results on vocabulary | Learners understood the terms | ISMS manager | [Learner log in `isms/isms-learning-path`] | Employment plus 2 years |

Map these records in `isms/control-evidence-matrix` (DOC-ISMS-033).

## 14. References

<!-- Guidance: Refer readers to the official terms. Check editions before each review. -->

| Standard | Edition | Link |
|---|---|---|
| ISO/IEC 27000 | 2026 (terms reduced compared with 2018) | https://www.iso.org/standard/84257.html |
| ISO/IEC 27001 | 2022 + Amd 1:2024 | https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html |
| ISO/IEC 27002 | 2022 | https://www.iso.org/standard/75652.html |
| ISO/IEC 27005 | 2022 | https://www.iso.org/standard/80585.html |
| ISO/IEC 27006-1 | 2024 | https://www.iso.org/standard/82908.html |
| ISO/IEC 17021-1 | 2015 | https://www.iso.org/standard/61651.html |
| ISO/IEC 27701 | 2025 | https://www.iso.org/standard/85819.html |
| ISO/IEC 27017 | 2026 | https://www.iso.org/standard/82878.html |
| ISO/IEC 42001 | 2023 | https://www.iso.org/standard/81230.html |
| ISO 31000 | 2018 | https://www.iso.org/standard/65694.html |
| ISO 19011 | 2026 | https://www.iso.org/standard/88984.html |

IAF mandatory documents (such as IAF MD 1:2023 on multi-site
certification) have been re-issued by Global Accreditation Cooperation
Incorporated (Global ACI), which replaced IAF and ILAC on 2026-01-01; IAF MD
1 is now Global ACI-TECH-3-001. Check the current issue on the Global ACI
website.

Related templates: `isms/isms-learning-path`,
`isms/iso-27001-clauses-explained`, `isms/isms-self-test`,
`isms/iso-27000-family-map`, `isms/isms-manual`,
`compliance/risk-methodology`, `compliance/statement-of-applicability`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 and the
vocabulary of the ISO/IEC 27000 family as described in ISO/IEC
27000:2026. Every definition and explanation is original text written in
plain language; no ISO or IEC definitions, notes or term entries are
reproduced, and the official terms in ISO/IEC 27000:2026 and in each
standard prevail. You need the official standards to implement or audit an
ISMS. Editions change: check the current edition on iso.org before you rely
on this glossary. This is a learning aid, not certification or legal
advice. Template licence: MIT.