ITIL 4 information security management is one of the 14 general management practices, and its purpose is to protect the information an organization needs to conduct its business. Beyond confidentiality, integrity and availability (CIA), ITIL 4 explicitly names two further security properties: authentication and non-repudiation. The practice owns policy and controls; other ITIL 4 practices carry those controls inside their own workflows.
Why information security management matters: the business cost of weak access controls
Information security management matters because the costliest breaches rarely begin with something exotic. They begin with a credential that still worked and an access right nobody revoked.
Verizon’s 2026 Data Breach Investigations Report, built on more than 22,000 breaches, found that credential abuse appears at some point in 39% of them, the most pervasive technique in the dataset. Exploitation of vulnerabilities has meanwhile overtaken it as the most common initial access vector, at 31%. The human element was present in 62% of breaches, a slight increase from the previous year’s 60%. The controls that should close that route are uneven: 37% of organizations had an admin account with multifactor authentication (MFA) disabled on an Infrastructure as a Service (IaaS) offering.
Source: Verizon, 2026 Data Breach Investigations Report, built on more than 22,000 breaches
ENISA’s 2026 threat landscape names public administration as the most targeted sector, in 32% of cases. Germany’s Federal Office for Information Security describes the national picture as remaining tense, with ransomware attacks reported to the federal police at 950, largely unchanged.
None of this means those organizations lacked an information security management system. Most had one. They lacked a dependable record of who was granted which access, who approved it, and when it should have ended.
Those are failures of authentication and provability, and they happen inside ordinary service management workflows rather than inside a security operations tool.
What are the five security properties in ITIL 4?
ITIL 4 names five security properties: confidentiality, integrity and availability (CIA), plus authentication and non-repudiation.
The purpose statement, as transcribed by itsm.tools from the official ITIL 4 practice material, reads: “The purpose of the information security management practice is to protect the information needed by the organization to conduct its business. This includes understanding and managing risks to the confidentiality, integrity, and availability of information, as well as other aspects of information security such as authentication and non-repudiation.”
The wording is non-exhaustive: authentication and non-repudiation are the two properties ITIL 4 explicitly names beyond the triad, not a closed list.
- CIA CIA describes the state of information: who can read it, whether it is intact, whether it is reachable.
- Authentication and non-repudiation Authentication and non-repudiation describe the provability of actions taken on it.
A program scored only against the triad can be fully compliant on paper and still unable to answer the question an investigation opens with: who approved this, and how do you know?
ITIL v3 filed the same material as IT security management inside Service Design. ITIL 4 moved it up into general management, 14 practices of the 34, and the two extra properties came with it.
What is the difference between authentication and non-repudiation?
Authentication proves an identity at the moment of access; non-repudiation produces evidence afterward that a specific actor took a specific action and cannot credibly deny it.
Authentication is enforced by identity tooling: directories, MFA, conditional access, almost always owned outside the service desk. Non-repudiation has no equivalent enforcement layer. It is produced, or not produced, by records.
Those records are the named approver on an access request, the authorizer recorded against a change, the owner attached to an access recertification decision, and the person who closed a security incident. Capture those at the time and non-repudiation exists. Backfill them, or let a shared service account stand in, and no tool can reconstruct them later.
This is the one security property an IT service management (ITSM) platform is structurally better placed to deliver than a security platform, and the one most organizations have never assigned to anyone.
Which ITIL 4 practices carry information security controls?
Information security management sets requirements that other practices execute, principally change enablement, service request management, service configuration management, incident management and deployment management.
As a general management practice it has no value stream and no queue of its own. Its only direct outputs are policy, control requirements and decision rights, and every control is performed inside somebody else’s workflow.
Access is the clearest case. Access management is not one of ITIL 4’s 34 management practices. Information security management sets the access policy, and the granting and revoking work is handled as predefined service requests. IT Process Maps puts the relationship this way: “The Access Management processes essentially execute policies defined in Information Security Management.”
That is also where the control surface is widest. Verizon’s 2026 report analyzed 176 MITRE ATT&CK privilege escalation and credential access techniques. About 65% are addressed by privilege management, with configurations and password policies following at 33% and 30%. Only about 10% are mitigated by applying patches.
Source: Verizon, 2026 Data Breach Investigations Report, analysis of 176 MITRE ATT&CK techniques
Read the boundary alongside the figure: Verizon notes that exploitation of vulnerabilities is far more traditionally present in incidents as an initial access vector and will only have limited presence in this technique analysis. The number says privilege management covers more privilege-escalation technique surface than patching does. It does not say patching matters less.
Teams still build the practice as though it did have a queue, with its own review board and its own ticket type. That turns it into a gate other practices learn to route around. It also means a security dashboard cannot tell you whether the practice is working.
The working test is a sample of other practices’ records, checked for the authorizer, the approver and the classification.
The method for weighing security risk belongs to the separate risk management practice, which information security management applies to information assets. Service configuration management matters just as much, because an approval is only evidence if the configuration management database (CMDB) says what it applied to.
How does a security incident differ from a normal incident in ITIL 4?
A security incident is handled through the same incident management practice, but the security policy adds two obligations a normal incident does not carry: preserving evidence, and containing before restoring.
The difference is the objective rather than the severity, and the objective inverts. Incident management exists to minimize the negative impact of incidents by restoring normal service operation as quickly as possible, and service desk targets reward exactly that.
Containment can require the opposite. Preserving system state, isolating an asset and accepting a longer outage may all be correct, and each one makes the team’s own measured performance worse.
A first-line agent cannot resolve that conflict mid-incident, which is why precedence has to be written down before one happens.
The information security policy has to set precedence in advance, not improvise case by case. Verizon’s 2026 report puts ransomware in 48% of all breaches, up from 44%, and records that 69% of victims did not pay. Where restoration overwrites system state, the same intrusion tends to come back.
Source: Verizon, 2026 Data Breach Investigations Report
Standards guidance has settled in the same place. NIST’s SP 800-61 Revision 3, published in April 2025, positions incident response inside continuous cybersecurity risk management rather than as a standalone procedure. Detection and triage tooling belongs with monitoring and event management. Information security management owns the narrow part that cannot be delegated: the decision rule, the restricted communication path and the evidence obligation.
What is the difference between ITIL 4 information security management and ISO 27001?
ISO/IEC 27001 specifies an auditable, certifiable Information Security Management System (ISMS); ITIL 4’s information security management practice describes how security controls are operated inside day-to-day service management, and it certifies nothing.
They do not compete. The management system defines what has to be evidenced, and the practice produces the evidence.
An ISO 27001 information security management system defines what must be documented, reviewed and sampled. According to IT Governance, Annex A of the 2022 edition lists 93 controls across four themes: organizational, people, physical and technological, with implementation guidance in the companion standard ISO/IEC 27002. The ITIL 4 practice decides whether the records an auditor asks for exist at all, because change, request, configuration and incident workflows produce them. IT Process Maps puts it directly: “ITIL does not provide a detailed explanation of all aspects of Information Security Management, as there are dedicated and more detailed standards available.”
Organizations routinely treat a Statement of Applicability as proof that controls operate.
It states which controls are in scope; it says nothing about whether last quarter’s privileged access grants carry an approver. Set side by side, the two answer different questions:
ITIL 4 information security management and ISO/IEC 27001 side by side
| Dimension | ITIL 4 information security management | ISO/IEC 27001 |
|---|---|---|
| What it is | One of ITIL 4’s general management practices | A specification for an Information Security Management System (ISMS) |
| Primary output | Security policy, control requirements and decision rights | A documented, auditable management system |
| Certifiable | No, the practice cannot be certified | Yes, organizations are certified against it |
| Control detail | Points to other practices and to external control sets | Annex A control set, with guidance in ISO/IEC 27002 |
| Where the work happens | Inside change, request, configuration and incident workflows | Inside the management system: scope, policy, review, internal audit |
| Security properties named | Confidentiality, integrity, availability, authentication, non-repudiation | Confidentiality, integrity and availability |
| Relationship to risk | Applies the organization’s risk management practice to information assets | Requires a defined information security risk assessment and treatment process |
| How the two meet | Produces the operational records an audit samples | Defines what must be documented, reviewed and sampled |
What should an information security policy in ITIL 4 cover?
An information security policy should cover the five security properties, information classification, access decision rights, acceptable use, and the obligation to report a suspected security incident.
Most policies cover the properties and the reporting duty, then leave the middle three unstated. Decision rights are the omission that matters, because a policy stating that information must be protected gives a change manager nothing to act on.
A policy that can be executed names who may authorize privileged access, who may waive a control and for how long, and who decides containment over restoration. It also accepts how people actually behave. Verizon’s 2026 report puts misuse at just under 4% of breaches, and notes it peaked at nearly 8% two editions earlier. Convenience, at 60%, outranks financial gain at 33%, and 54% of those actors are described as your average end user.
Source: Verizon, 2026 Data Breach Investigations Report
Those numbers describe a governance problem. Most misuse comes from ordinary users taking the convenient route, so the fix is control design rather than detection.
A policy drafted on the assumption of bad intent produces controls people work around. Designing for inconvenience instead means making the approved path the easiest one.
Key takeaways
- Five properties, not three ITIL 4 explicitly names authentication and non-repudiation alongside confidentiality, integrity and availability. A program scored only against the CIA triad leaves two of ITIL 4’s named properties with no owner and no evidence.
- The practice has no queue of its own As a general management practice, information security management produces policy and control requirements rather than tickets. Its controls are executed inside change enablement, service request management, service configuration management, incident management and deployment management.
- Non-repudiation is produced by records, not tools Authentication is enforced by identity tooling. Non-repudiation is not enforced by anything: it exists only if the approver on an access request, the authorizer on a change and the owner of a recertification decision were captured at the time.
- A security incident inverts the restoration instinct Normal incident handling optimizes for the fastest restoration of service. A security incident may require preserving system state and accepting a longer outage, so the information security policy, not the service desk’s targets, has to set that precedence in advance.
- ISO 27001 certifies the system, ITIL 4 operates the controls An Information Security Management System (ISMS) defines what must be documented, reviewed and sampled. The ITIL 4 practice determines whether the records an auditor samples actually exist, because service management workflows are what produce them.
Proof of who approved what, and when
The security property you cannot buy is the one your service desk has been generating all along, in approval fields nobody reads until an auditor asks for them.
Matrix42 is an IT service management and digital workspace vendor rather than a security platform, and the boundary is worth stating plainly. Matrix42 Enterprise 25.4 is PinkVERIFY-certified on 11 ITSM processes until March 3, 2027, and information security management is not one of them. It is a listed platform capability in the Core and Professional expansion set. What the platform holds is the evidence layer.
Matrix42 Identity Governance and Administration (IGA) records the named approver on every access request, runs access rights recertification and removes accounts and entitlements automatically when a person leaves. The Matrix42 service management platform keeps the authorizer and approval trail on changes and service requests in the same system of record as the affected asset.
Matrix42 Unified Endpoint Management adds patch compliance reporting, and the AI Agent for Security Patch Gap Advisory cross-references a ticket’s associated asset against those reports, then alerts the security lead with recommended remediation rather than acting on its own. Matrix42 Endpoint Data Protection blocks a data exfiltration attempt in real time and creates a security incident ticket automatically, so the handling path starts in the records the policy is audited against. At Landkreis Landshut, that record is what the auditor sees: contracts, assets, servers, patch management and the server journals, produced on demand for the district’s ISMS documentation.
Evidence you can produce
An approval nobody recorded is not a control, however well the policy reads. See how change, request and asset records sit in one system of evidence in Matrix42 IT service management.
Explore the future of ITSM→FAQs
The CIA triad is confidentiality, integrity and availability: the three properties that classical information security practice treats as the definition of a protected asset. It predates ITIL and is not an ITIL invention. ITIL 4 adopts the triad as the core of its practice but treats it as incomplete, naming authentication and non-repudiation alongside it.
Scope. Information security management covers all information the organization relies on, in any form, including paper records, verbal disclosure and supplier-held data. Cybersecurity covers digital systems, networks and the threats against them. ITIL 4’s practice is the broader of the two, which is one reason it is classified as a general management practice rather than a technical one.
No. ITIL 4 does not require a formal Information Security Management System (ISMS) or any certification. It expects a documented security policy, named decision rights and controls embedded in other practices. An ISMS is one way to formalize and audit that arrangement, and organizations seeking ISO/IEC 27001 certification will need one.
Yes, but not as a separate practice. Security incidents run through the incident management practice, with additional obligations set by the information security policy: evidence preservation, containment precedence and a restricted communication path. ITIL 4 deliberately avoids a parallel security incident process, because a second queue splits triage and delays the first response.
Accountability sits with organizational governance, typically a board-level or executive owner, because the policy constrains the whole organization and not only IT. An information security manager usually authors and maintains it. Individual controls are owned by the practices that execute them, so the change manager owns change authorization evidence, not the security team.
Useful measures are mostly records-based rather than threat-based. Track the percentage of changes with a recorded authorizer, the access recertification completion rate, and the time to revoke access after a leaver date. Add the number of active policy exceptions and their age, and the proportion of assets with a current classification. Threat counts measure the environment, not the practice.
Information security management is one consumer of the organization’s risk management practice. Risk management supplies the shared method for identifying, assessing and handling risk across all domains; information security management applies it to information assets and translates the output into policy, controls and classification. Treating security risk as a separate parallel method produces two conflicting registers.
Related articles
ITIL 4 practiceWhat is ITIL 4 Service Request Management? Process, examples and guideRead the article →
ITIL 4 topicWhat is a Configuration Management Database (CMDB)?Read the article →
ITIL 4 practiceWhat is ITIL 4 Monitoring and Event Management? Categories, AIOps and MTTD guideRead the article →
ITIL 4 overviewITIL 4 practices for IT Service ManagementRead the article →
ITIL 4 practiceWhat is ITIL 4 Measurement and Reporting? Metrics, KPIs and practice guideRead the article →
Sources
- 1 Verizon, “2026 Data Breach Investigations Report,” 2026.verizon.com/business/resources/reports/dbir
- 2 ENISA (European Union Agency for Cybersecurity), “ENISA Threat Landscape 2026,” 2026.enisa.europa.eu/publications/enisa-threat-landscape-2026
- 3 Bundesamt für Sicherheit in der Informationstechnik (BSI), “Die Lage der IT-Sicherheit in Deutschland 2025,” 2025.medien.bsi.bund.de/lagebericht/de/index.html
- 4 itSM.tools, “ITIL 4 Management Practices Explained: Full List and Purposes,” 2026.itsm.tools/34-itil-4-management-practices
- 5 IT Process Maps, “IT Security Management / Information Security Management,” 2026.wiki.en.it-processmaps.com/index.php/IT_Security_Management
- 6 IT Process Maps, “ITIL Service Operation,” 2026.wiki.en.it-processmaps.com/index.php/ITIL_Service_Operation
- 7 IT Governance, “Your Guide to ISO/IEC 27001:2022,” 2026.itgovernance.co.uk/iso27001
- 8 NIST, “SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management,” 2025.csrc.nist.gov/pubs/sp/800/61/r3/final