Two ideas sit “upstream” of risk registers and SoA tables: who matters to your information security decisions, and what you are trying to achieve in measurable terms. ISO 27001 expects both to be understood and maintained as the organisation changes.
What are interested parties?
Interested parties (sometimes called stakeholders) are individuals or organisations who can affect your ISMS or be affected by it. Typical examples include customers who contract for security outcomes, regulators who impose breach notification rules, boards that set risk appetite, employees who handle data, owners of critical suppliers, insurers, and industry groups.
The point of listing them is not paperwork—it is to make requirements explicit. A hospital’s interested parties differ from a SaaS startup’s; your scope, legal register, and control priorities should trace back to their legitimate needs and expectations.
What you capture in practice
- Who they are and their relationship to your organisation.
- Which requirements matter for information security (contractual clauses, law, internal policy, brand promise).
- How you stay current (review triggers when laws or contracts change).
What is an objectives register?
An information security objectives register is the structured list where you turn high-level policy (“we protect customer data”) into SMART-style objectives: specific outcomes, owners, timelines, and how you will measure success. Objectives should be consistent with your information security policy and aligned to risk treatment—otherwise the ISMS reads as disconnected slogans.
Typical columns
- Objective statement and link to risk or compliance driver.
- Owner and contributing teams.
- Target date or cadence for review.
- Key performance or effectiveness indicators (metrics, test pass rates, incident counts).
- Status and evidence pointer (report, dashboard, minutes).
Management review (and certification audits) often sample objectives to see whether leadership actually uses the ISMS to steer—not only whether documents exist.
How parties, objectives, risk, and SoA connect
Interested parties supply requirements. Objectives state how you will meet those requirements over time. The risk assessment identifies gaps between current state and requirements; the SoA and control library describe how you implement treatment. When any upstream item changes—new regulator, new product line—you should refresh context, objectives, risks, and applicability in that order to avoid silent drift.
For risk-specific ISO clauses, see ISO 27001 risk management requirements. For the SoA, start with what is a Statement of Applicability?
Document objectives and policies in one suite
Use Document Management for controlled policy packs; use Risk Management for registers, controls, and SoA—together they support a coherent ISMS evidence story.
Document Management