ISO 27001 clause 3: Terms and definitions
ISO 27001 clause 3 points to the terminology in ISO/IEC 27000. Its practical value is consistency: business managers, technical teams and auditors should understand the same concepts when discussing security outcomes. This page gives original working explanations and examples; it does not reproduce or replace the standard’s formal definitions.
What clause 3 requires in practice
Clause 3 is deliberately brief. It says the terms and definitions used in ISO 27001 are those given in the ISO/IEC 27000 vocabulary document, and it points to the international terminology databases maintained by the standards bodies for anyone who needs to browse them.
The practical consequence is that words such as risk, control, interested party, nonconformity or documented information carry a defined meaning throughout the ISMS. An organisation can still use friendly working language with its staff, but when an auditor reads a procedure or asks a question, the formal meaning is the reference point. Where internal wording differs from the formal meaning, the organisation should be ready to explain how the two relate.
The clause produces no record. Its outcome is consistent understanding between management, technical teams and assessors, so that a discussion about a risk or a nonconformity is about the same thing for everyone involved.
Agree meanings before designing the process
Information security concerns confidentiality, integrity and availability. A risk discussion can therefore address unauthorised disclosure, unreliable information or inability to access a service when needed. Labelling all three simply “data breach” can conceal different consequences and treatment needs.
A control is a measure used to address risk; an objective is an intended result. Installing a backup system is not the same as demonstrating that important information can be restored within business needs. Likewise, a risk owner is not automatically the technician assigned to implement one safeguard. Authority to accept a business exposure deserves explicit consideration.
How to put clause 3 to work
The aim is working understanding, not copied definitions. One approach used by Sterling teams is a short glossary written in the organisation's own words and checked against the reference.
- Pick the dozen or so terms that cause most confusion in your business, such as risk owner, control, objective and nonconformity.
- Read the formal meaning in the vocabulary document and note where everyday usage in your teams differs.
- Write a plain-language explanation for each term with an example from your own services.
- Review existing policies and procedures, correcting places where a term is used in a way that conflicts with its meaning.
- Brief managers and process owners, using real cases to show how the terms apply to decisions.
- Ask internal auditors to use the same terms in findings and reports.
- Refresh the working explanations whenever auditors, customers or staff raise a misunderstanding, since recurring confusion usually shows where a term is being used loosely or where training needs a better example from daily work.
Evidence an auditor expects for clause 3
Auditors do not usually request a definitions record. They look for signs that terms are used correctly in daily work.
- Interviews in which process owners describe risk, control and nonconformity in a way that fits the standard.
- Procedures and reports whose wording is consistent from one document to the next.
- Internal audit reports that classify findings using the correct terms.
- Any working glossary the organisation chose to keep, treated as helpful rather than required.
Where a customer or auditor asks a question, the way the team answers it, in the correct sense of the terms, is often the most convincing evidence of all.
Separate events, incidents and nonconformities
An observed event needs assessment before the organisation decides whether it is an incident and what response is required. A nonconformity concerns failure to meet an applicable requirement. One incident can reveal a nonconformity, but an incident is not automatically proof that every relevant control failed, nor is every procedural nonconformity an incident.
These distinctions affect records. A risk assessment records the exposure and its evaluation; an incident record tracks what happened and the response; a corrective-action record addresses an applicable requirement that was not met and whether causes were dealt with. Link records when appropriate rather than copying the same description into every register.
Illustrative examples
A deployment makes a customer portal unavailable without exposing confidential data. Availability is still an information security concern. The team investigates the event, determines its incident classification and checks whether change controls were followed. Corrective action depends on the actual requirement failure, not the fact that customers were inconvenienced alone.
A reviewer finds a former employee account left active. The access-removal requirement was not met even if logs show no later use. Closing the account corrects the immediate problem. Investigating why the HR-to-IT handover failed addresses the cause; the organisation also checks whether other departures were affected.
Build consistent understanding without unnecessary paperwork
Use a short workshop or the opening section of your risk method to resolve terms that affect decisions. Ask staff to apply them to a real business scenario. A company glossary can help a multilingual or multisite organisation, but clause 3 does not demand a separate glossary document.
Keep terms aligned across the risk method, Statement of Applicability, audit findings and management reports. Avoid inventing local definitions that reverse the meaning of a referenced concept. Consult the authorised vocabulary when a formal distinction matters, and use competence development to address misunderstanding rather than merely collecting attendance signatures.
Frequently asked questions
Do we need to copy ISO definitions into every ISMS procedure?
No. Consistent understanding matters more than repeating definitions. Use authorised references where precise terminology is needed and explain how your own process applies the concepts.
Is every security incident a nonconformity?
No. Examine whether an applicable requirement was not met. An incident may reveal a nonconformity, but classification and corrective action should follow evidence rather than assumption.
Is a training certificate enough to show terminology is understood?
It can support learning evidence, but practical application is more persuasive. Ask people to explain and use key distinctions in decisions relevant to their responsibilities.
Give your team a shared working vocabulary
Talk to Sterling to run a practical discussion of risk, incidents, controls and nonconformities using examples from your own operations. Build the relevant knowledge through ISO/IEC 27001:2022 Awareness at Sterling Academy. Certification decisions remain with an independent certification body.