< Previous standard ^ Up a level ^ Next standard >
ISO/IEC TS 27022:2021 — Information technology — Guidance on information security management system processes
“This document defines a process reference model (PRM) for the domain of information security management, which is meeting the criteria defined in ISO/IEC 33004 for process reference models (see Annex A). It is intended to guide users of ISO/IEC 27001 to: incorporate the process approach as described by ISO/IEC 27000:2018, 4.3, within the ISMS; be aligned to all the work done within other standards of the ISO/IEC 27000 family from the perspective of the operation of ISMS processes; support users in the operation of an ISMS. This document is complementing the requirements-oriented perspective of ISO/IEC 27003 with an operational, process-oriented point of view.”
[Source: ISO/IEC TS 27022:2021]
The standard (a Technical Specification) “provides a process reference model (PRM) for information security management, which differentiates between ISMS processes and measures/controls initiated by them ... [and] describes the ISMS processes implied by ISO/IEC 27001.”
The standard is based on a PhD thesis submitted to the Universidad Carlos III de Madrid, Spain.
According to the scope, the standard “is intended to guide users of ISO/IEC 27001 to:
- incorporate the process approach as described by ISO/IEC 27000:2018 clause 4.3 within the ISMS
- be aligned to all the work done within other standards of the ISO/IEC 27000 family from the perspective of the operation of ISMS processes
- support users in the operation of an ISMS – the document will complement the requirements oriented perspective of ISO/IEC 27003 with an operational, process oriented point of view.”
The standard does not define any new ISMS requirements, beyond those already defined in ISO/IEC 27001. In other words, it is advisory rather than mandatory.
Purpose and justification
The standard lays out, in some detail, a Process Reference Model comprising a generic suite of ISMS processes that organisations may wish to use as a basis for designing custom processes within their own ISMS.
Structure and content
The ISMS processes described fall into 3 “categories” (types or groups) i.e.:
- Governance activities (confusingly titled ‘management processes’) - direction and oversight for the ISMS;
- Core operations e.g. information risk and security management, policy management, incident management, internal audits ...; and
- Support e.g. records management, communicating with interested parties about the ISMS, managing relationships with ISMS ‘customers’ ...
The processes are each laid out in an Appendix, first as a table specifying:
- Process “category” denoting the type of process
- A brief description
- Input[s] and Output[s]
- Activities/functions i.e. a few words for each of the main steps in the process
- Informative references.
The table is followed by a flowchart summarising the process on one side or less.
ISO/IEC TS 27022 was first published in 2021.
It is hardly a revolutionary approach to treat an ISMS as a suite of processes. Many reasonably mature organisations already have processes for:
- Asset management;
- Audit management, both internal and external;
- Business continuity management (see ISO 22301);
- Change management plus configuration management and version control;
- Continuous improvement and maturity management;
- Database [security] management;
- Exemption management (management-approved noncompliance with policies);
- Facilities management including power and other services for the computer room;
- Identity, access rights and user account management;
- Incident management including incident investigation and forensics;
- Information management in general;
- Information [security] risk management (partly covered by ISO/IEC 27005);
- Information security management (covered by ISO/IEC 27001, 27002, 27003 and others);
- Internal audits and certification audits;
- Key management, plus the rest of cryptography;
- Log management, plus alarms and alerts;
- Metrics and management information management (partly covered by ISO/IEC 27004);
- Monitoring and oversight of the risk management and security arrangements;
- Patching, including emergency arrangements for urgent fixes;
- Performance and capacity management;
- Personnel/HR management including “onboarding” and “offboarding” (nasty neologisms!);
- Preventive and corrective actions;
- Quality management, especially quality assurance;
- Service management [organisations that are heavily process-oriented may be using ITIL/ISO20000, in which case ISO/IEC 27013 is applicable];
- Supplier/vendor relationship management, including telecomms, Internet and cloud services, outsourced development, contract security guards, maintenance/servicing, professional services/consulting/contracting etc.;
- System and network [security] management;
- System/software development and testing ...
... and more.
Providing generally-applicable advice without imposing further constraints is challenging. The processes need to be described without losing the flexibility to cater for myriad differences between organisations. In particular, the processes need to be valuable (cost-effective) in practice to justify their existence, for instance by:
- Removing unnecessary bureaucracy, rationalising and justifying whatever remains;
- Facilitating or encouraging process automation and innovation where applicable;
- Facilitating or encouraging use of existing processes, adapting them where necessary;
- Perhaps re-using effective ISMS processes elsewhere in the organisation;
- Managing the processes themselves e.g. processes for monitoring, reviewing, evaluating and maintaining the processes, responding to changes, exploiting improvement opportunities etc.
Despite overall approval, during drafting there were adverse comments about the implication that ISMS processes are distinct from normal operations, rather than being integral to the organisation’s routine activities. The process for managing an information security or privacy incident, for example, is essentially the same as that for managing any other incident, hence it is generally unnecessary to create another, parallel incident management process if the existing one (perhaps with a few tweaks) is effective. The standard is intended to be advisory rather than compulsory, and “is not intended to be used ‘out of the box’ without adapting it to the implementing organisation” (quoting from section 4 of the draft).
< Previous standard ^ Up a level ^ Next standard >