ISMS policies
ISO/IEC TS 27022

Search this site

ISMS templates

< Previous standard      ^ Up a level ^      Next standard >


ISO/IEC TS 27022 — Information security, cybersecurity and privacy protection — Guidance on information security management system processes [DRAFT]



The standard set out to “provide a process reference model (PRM) for information security management, which clearly differentiates between ISMS processes and measures/controls.”

The standard is based on a PhD thesis submitted to the Universidad Carlos III de Madrid, Spain.



According to the 1st Committee Draft: “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
  • incorporate all the work done within other standards of the ISO 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 should supplement ISO/IEC 27001, 27003 etc. “with an operational, process oriented perspective. So it will not be in conflict or duplicate the content of existing standards.”


Purpose and justification

The standard lays out, in some detail, a Process Reference Model comprising a generic suite of ISMS processes that organizations may with 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
  • Objective/purposes
  • 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.



Drafting commenced in 2018.

Sept The standard was due by 2022 but has progressed rapidly and looks likely to be published in 2021.

It is currently at 2nd Committee Draft stage. It will probably be published as a Technical Specification rather than an International Standard.


Personal comments

It is hardly a revolutionary approach to treat an ISMS as a suite of processes.  Many reasonably mature organizations already have processes for:

  1. Business continuity management (see ISO 22301);
  2. Change management plus configuration management and version control;
  3. Continuous improvement and maturity management;
  4. Database [security] management;
  5. Exemption management (management-approved noncompliance with policies);
  6. Identity, access rights and user account management;
  7. Incident management including incident investigation and forensics;
  8. Information management in general;
  9. Information [security] risk management (partly covered by ISO/IEC 27005);
  10. Information security management (covered by ISO/IEC 27001, 27002, 27003 and others);
  11. Internal audits and certification audits;
  12. Key management, plus the rest of cryptography;
  13. Log management, plus alarms and alerts;
  14. Metrics and management information management (partly covered by ISO/IEC 27004);
  15. Performance and capacity management;
  16. Preventive and corrective actions;
  17. Quality management, especially quality assurance;
  18. Service management [organizations that are heavily process-oriented may be using ITIL/ISO20000, in which case ISO/IEC 27013 is applicable];
  19. Supplier/vendor relationship management;
  20. System and network [security] management;
  21. System/software development

... 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 organizations. 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 organization;
  • Managing the processes themselves e.g. processes for monitoring, reviewing, evaluating and maintaining the processes, responding to changes, exploiting improvement opportunities etc.

Sept Despite overall approval, there have been 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 organization” (quoting from section 4 of the draft).


< Previous standard      ^ Up a level ^      Next standard >

Copyright © 2020 IsecT Ltd.