Key Concepts and Terminology

A set of policies, processes, procedures, and controls — governed by management and continually improved — that an organization uses to manage information security risks in a systematic, auditable way. The ISMS is not a product or a platform. It is a management system: a structured approach to governing how your organization handles information security.

Example: A fintech company's ISMS might cover its core payment processing service, encompassing the people, systems, physical locations, and third-party relationships involved in delivering that service — with documented policies, risk assessments, implemented controls, and evidence of management oversight.

Anything that has value to the organization and contains or processes information. This includes data (in any form), software, hardware, services, people, and intangibles like reputation. The 2022 version of ISO 27002 groups assets into information assets, software assets, physical assets, services, people, and intangible assets.

Example: For a hospital: patient records (information asset), the electronic health records system (software asset), the servers hosting it (physical asset), the cloud hosting provider (service asset), and the clinical staff who access it (people).

The individual or entity with approved management responsibility for an asset — including accountability for ensuring the asset is appropriately protected. Asset ownership is a formal accountability assignment, not just whoever uses the asset most.

Example: The Head of Engineering is the asset owner for the customer database. They are accountable for ensuring access controls, backup procedures, and encryption standards are maintained — even if the daily operations are handled by their team.

The effect of uncertainty on objectives. In the information security context: the potential that a threat will exploit a vulnerability in an asset, causing harm to the organization. Risk is always a combination of likelihood (how probable is it?) and impact (how bad would it be?). ISO 27001 does not prescribe a specific risk calculation method — it requires that your method is defined, documented, and consistently applied.

Example: The risk that an unauthorized actor gains access to customer personal data through a phishing attack targeting staff with database access.

The person or entity with the accountability and authority to manage a risk. The risk owner approves the risk treatment decision, accepts any residual risk, and is accountable for the outcome. Risk owners are typically business managers, not security staff — because they own the assets and processes that carry the risk.

Example: The Chief Financial Officer is the risk owner for financial reporting system risks, not the CISO. The CISO advises; the CFO decides and is accountable.

The risk that remains after risk treatment controls have been applied. No control eliminates risk entirely — residual risk is what is left over, and it must be formally accepted by the risk owner. The level of residual risk that an organization is willing to accept is determined by its risk appetite.

Example: After implementing MFA, encryption, and access logging on the customer database, a residual risk remains that a malicious insider with legitimate access could still exfiltrate data. The risk owner reviews this residual risk and formally accepts it, noting it in the risk register.

The amount and type of risk that an organization is willing to pursue or retain in order to achieve its objectives. Risk appetite is set by top management and defines the threshold below which residual risks are acceptable without further treatment. It is a strategic decision, not a technical one.

Example: A regulated bank may have a near-zero risk appetite for risks involving customer personal data, but a moderate risk appetite for risks related to internal operational inefficiency.

A documented plan describing the controls to be implemented, the timeline for implementation, the resources required, and the responsible owners — for each risk selected for treatment. The risk treatment plan is a required output of the risk assessment process and is reviewed by auditors as evidence that the ISMS is operationally driven by risk.

Example: A documented plan stating: 'Implement MFA on all database admin accounts by Q2 2026. Responsible: Head of Engineering. Budget: approved. Status: in progress.' Each treated risk has an entry like this.

A measure that modifies risk. Controls can be preventive (reducing likelihood), detective (identifying when a risk event has occurred), or corrective (reducing impact after an event). Controls exist at the organizational level (policies, procedures), the people level (training, background checks), the physical level (locks, CCTV), and the technological level (encryption, firewalls, logging).

Example: Encrypting data at rest is a preventive control that reduces the likelihood of unauthorized access being useful even if a breach occurs. An intrusion detection system is a detective control that alerts when unauthorized access is occurring.

A document that lists all 93 Annex A controls, states whether each is applicable or excluded, provides the justification for each decision, and records the implementation status of applicable controls. The SoA is one of the most scrutinized documents in a certification audit — it is the bridge between the risk assessment and the control set.

Example: Control A.8.3 (Information access restriction) is listed as applicable because the risk assessment identified unauthorized access to customer data as a high risk. Control A.7.4 (Physical security monitoring) is excluded because the organization operates fully remotely with no physical office.

Any person or organization that can affect, be affected by, or perceive itself to be affected by the organization's information security decisions. Identifying interested parties and understanding their requirements is a mandatory first step in defining the ISMS scope. Interested parties typically include customers, regulators, employees, suppliers, shareholders, and in some cases the public.

Example: For an Indonesian fintech company: Bank Indonesia (regulator), OJK (financial services regulator), customers whose data is processed, cloud infrastructure providers, and the company's own employees all qualify as interested parties with specific information security requirements.

The person or group of people who directs and controls the organization at the highest level. In ISO 27001, top management has non-delegable responsibilities: establishing the information security policy, ensuring the ISMS is integrated into business processes, demonstrating leadership and commitment, and participating in management reviews. This cannot be delegated entirely to the CISO.

Example: The CEO and board of directors are top management. Their responsibility is not to manage controls day-to-day — it is to set direction, provide resources, and be accountable for the ISMS outcomes at the organizational level.

The ability to apply knowledge and skills to achieve intended results in information security. ISO 27001 requires that anyone whose work affects information security performance has the necessary competence — and that evidence of that competence is retained (training records, qualifications, experience documentation).

Example: A cloud infrastructure engineer responsible for implementing encryption controls must be demonstrably competent in encryption technologies. A training record, certification, or documented work experience constitutes evidence.

A systematic, independent, documented process for obtaining evidence and evaluating it objectively to determine the extent to which the ISMS meets the organization's own requirements and the requirements of ISO 27001. Internal audits are conducted by the organization itself (or by a third party on its behalf) and are a mandatory requirement — not a preparation activity for external certification.

Example: A planned internal audit examines whether access review procedures are being followed. The auditor samples five systems, reviews access logs, interviews the IT manager, and produces a report finding one nonconformity: quarterly access reviews are documented for four systems but overdue for one.

A failure to meet a requirement — either a requirement of ISO 27001 itself or a requirement the organization has set for itself in its own ISMS documentation. Nonconformities can be major (a systemic failure that casts doubt on whether the ISMS is functioning) or minor (an isolated lapse that does not indicate systemic breakdown). Both require documented corrective action.

Example: Major nonconformity: No risk assessment has been conducted since the ISMS was implemented three years ago. Minor nonconformity: The asset register was last reviewed 14 months ago rather than the 12-month cycle documented in the policy.

A formal, documented review of the ISMS by top management at planned intervals. The management review must cover defined inputs (audit results, risk treatment status, performance metrics, stakeholder feedback) and produce documented outputs (decisions on improvement opportunities, resource needs, and changes to the ISMS). It is not optional and not delegatable.

Example: An annual management review meeting attended by the CEO, CFO, and CISO reviews the past year's audit findings, incident log, risk register updates, and control performance metrics. The minutes document decisions made — including a budget allocation for a new DLP tool — and are retained as evidence.

The recurring activity of enhancing the ISMS to improve information security performance over time. Continual improvement is not a project — it is an ongoing organizational behavior. It is evidenced through corrective actions, changes to the ISMS driven by audit findings and management reviews, and the progressive maturation of controls and processes over successive certification cycles.

Example: After a phishing simulation reveals that 22% of staff clicked a malicious link, the organization updates its awareness training program, implements email filtering improvements, and tracks improvement in the next simulation six months later. This cycle — find the gap, fix it, verify the fix — is continual improvement in practice.