InfoSec Terminology Management — SOC 2 & ISO 27001 Controlled Vocabulary

Short answer

InfoSec terminology management is the controlled definition, approval, and versioning of security terms used across ISMS documentation. SOC 2 and ISO 27001 auditors check that terms like “incident,” “event,” and “authorized user” are defined once, approved by a second reviewer, version-controlled, and used consistently in policies. A Confluence-native glossary with four-eyes approval and audit export satisfies these expectations without an enterprise GRC platform.

The Problem: Inconsistent Security Terminology

Open your incident response plan, your risk assessment methodology, and your access control policy. Search for the word “incident.” You will find at least two different definitions — possibly three.

This is not a documentation style issue. It is a control gap.

ISO/IEC 27000:2018 defines an information security incident as a single or series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security. NIST SP 800-61r3 (citing FISMA, PL 113-283) defines an incident as “an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies” (source). The ISO definition turns on events with “significant probability” of compromise; NIST includes “imminently” jeopardizing systems. Those framing differences change your incident classification threshold, your reporting timelines, and your escalation criteria.

The same ambiguity affects vulnerability vs. weakness, breach vs. incident, event vs. alert, and risk appetite vs. risk tolerance. These are not interchangeable. Each has a specific meaning in ISO 27000, NIST SP 800-53, and SOC 2 Trust Services Criteria. Your ISMS documentation should use one consistent, approved set of definitions.

What Auditors Actually Examine

Both SOC 2 and ISO 27001 auditors assess terminology governance — though they frame it differently.

ISO 27001:2022

• Clause 7.5 — Documented information: Requires that ISMS documentation is controlled, versioned, and available in its current form. If your security glossary is required by your ISMS and exists as an unversioned wiki page, it will not satisfy the control expectations in 7.5.2 (approval for suitability/adequacy) or 7.5.3 (version control, change control, retrieval). See ISO/IEC 27001:2022.
• Annex A 5.3 — Segregation of duties: ISO/IEC 27002:2022 Annex 5.3 (Segregation of duties) requires that conflicting duties and conflicting areas of responsibility be separated to reduce opportunities for unauthorized or unintentional modification or misuse of organizational assets. A security term definition that governs incident classification is a critical change, and applying dual authorization (commonly called the four-eyes principle) is a recognized way to operationalize this separation when one person would otherwise both author and approve the change.

SOC 2 (Trust Services Criteria)

• CC6.1 — Logical and physical access controls: Auditors evaluating CC6.1 often cross-check access-related terminology across policies — inconsistent definitions of terms like “authorized user” weaken the evidence of a coherent access control design. If “authorized user” means one thing in your access control policy and something different in your acceptable use policy, that inconsistency weakens the control environment. See AICPA Trust Services Criteria.
• CC7.2 — System monitoring: CC7.2 addresses monitoring system components for anomalies indicative of malicious acts, natural disasters, or errors, and analyzing those anomalies to determine whether they represent security events. If the definitions of “anomaly,” “event,” and “incident” drift across documents, the analysis step becomes hard to evidence consistently.

What the auditor checks

How Compliance Glossary Addresses These Requirements

Compliance Glossary is a Confluence app that provides terminology governance directly where your ISMS documents already live. No data migration, no new platform to learn, no separate login.

Four-eyes approval — Annex A 5.3 alignment

Every term definition requires approval from a second authorized person. The system technically prevents self-approval — enforced server-side, not by policy. This aligns with ISO/IEC 27002:2022 Annex 5.3 (Segregation of duties), which requires that conflicting duties and conflicting areas of responsibility be separated to reduce the risk of fraud, error, or unauthorized change. Dual authorization is one recognized way to enforce that separation when the same role would otherwise both author and approve a controlled definition. See our four-eyes principle implementation for the full control design.

Version history — Clause 7.5 compliance

Every change to a term definition is recorded: who changed it, what changed (full diff), when, and the approval decision with rationale. This creates the documented information lifecycle required by ISO 27001 Clause 7.5.2 and 7.5.3. No reconstruction from email threads or Confluence page history.

Compliance scanning — consistency enforcement

Scan your Confluence pages to find where security terms are used inconsistently. Identify pages where “incident” appears without referencing the approved definition, or where deprecated terms are still in use. This provides evidence for SOC 2 CC7.2 that your monitoring terminology is consistently applied.

Audit export — ready evidence packages

Export your complete glossary with full approval history, version diffs, and reviewer details. Hand the auditor a single document instead of pointing them at scattered wiki pages. This directly supports the evidence requirements for both ISO 27001 surveillance audits and SOC 2 Type II examinations.

Framework Mapping: Features to Controls

Each Compliance Glossary capability maps to specific controls across ISO/IEC 27001:2022, SOC 2 Trust Services Criteria, and NIST CSF.

Enterprise GRC Platforms vs. Compliance Glossary

Enterprise GRC platforms like ServiceNow GRC, RSA Archer, and OneTrust include terminology management as part of a broader governance suite. They are designed for organizations with dedicated GRC teams, multi-year implementation budgets, and complex integration requirements.

If you need policy lifecycle management, third-party risk scoring, continuous control monitoring, and automated compliance workflows — an enterprise GRC platform is the right choice. But if your specific problem is terminology governance for ISMS documentation, you do not need a platform that is typically a six-figure annual commitment with multi-quarter implementation cycles, per analyst commentary.

Compliance Glossary does not replace your GRC platform. It solves the specific problem of controlled terminology in your documentation environment — at a cost and timeline that makes sense for teams that are not ready for, or do not need, a full enterprise GRC suite.

SOC 2 & ISO 27001 Terminology Control — Without Enterprise Pricing

Your ISMS documents are in Confluence. Your terminology governance should be there too. Defined terms, four-eyes approval, version history, audit export — operational in minutes.

Frequently Asked Questions

Does ISO 27001 require a glossary?

ISO 27001:2022 does not mandate a glossary by name. However, Clause 7.5 requires that documented information determined by the ISMS is controlled, versioned, and available in its current form. If your ISMS relies on defined security terms, those definitions fall under 7.5.2 (creation, approval for suitability) and 7.5.3 (version control, change control, retrieval). An unversioned wiki page does not satisfy those control expectations.

What is the four-eyes principle in InfoSec documentation?

The four-eyes principle (dual authorization) requires that a second authorized person reviews and approves a change before it takes effect. In InfoSec documentation, this means a term definition cannot be created and self-approved by the same user. ISO/IEC 27002:2022 Annex 5.3 (Segregation of duties) requires conflicting duties and conflicting areas of responsibility to be separated to reduce fraud, error, and misuse risk; dual authorization is one recognized way to enforce that separation. Enforced server-side, it provides independent review evidence for auditors.

How is SOC 2 CC6.1 different from ISO 27001 A.5.3?

SOC 2 CC6.1 covers logical and physical access controls — the entity implements controls to restrict access. ISO 27001 Annex A 5.3 covers segregation of duties — conflicting duties and conflicting areas of responsibility are segregated. They overlap on authorization terminology but address different questions: CC6.1 asks whether access is restricted consistently; A.5.3 asks whether no single person controls conflicting parts of a process.

Do we need a GRC platform for terminology management?

No. Enterprise GRC platforms include terminology management as a minor feature within a broader governance suite designed for large programmes with dedicated GRC teams. If your specific problem is controlled ISMS terminology — defined terms, approval workflow, version history, audit export — a Confluence-native app solves it without the implementation cycle and cost of a full GRC platform.