Information security management for service managers

Every practice in this course touches information security. Configuration and asset data show what must be protected. Releases and deployments can introduce vulnerabilities or close them. Suppliers handle sensitive data. Service levels include availability, which is one of the three classic goals of security. Continual improvement must include security improvements. This lesson explains information security management at the level the ITIL Foundation exam expects and that every service manager needs: its purpose, the core concepts, the balance between prevention, detection and correction, how security is woven into other practices, and how it is measured. The CISSP courses, CISSP-113 to CISSP-116, cover security in much greater depth.

Purpose of information security management

In plain words, 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 (ensuring someone is who they claim to be) and non-repudiation (ensuring that someone cannot deny that they took an action). The purpose is framed around the business: information is protected because the organization needs it, and the level of protection should match the value and risk involved.

In ITIL 4, information security management is a general management practice. Published summaries of ITIL (Version 5), checked in October 2026, list it in the product and service management group instead, reflecting how closely security is now built into the design and operation of products and services. Its core purpose is described in similar terms.

Confidentiality, integrity and availability

The three classic properties of information security are often called the CIA triad. Confidentiality means information is accessible only to those authorized to see it. Integrity means information is accurate and complete and is changed only in authorized ways. Availability means information and systems are accessible to authorized users when needed. Different information needs different emphasis. Larchmont's payroll data demands strong confidentiality; its shipment records demand integrity, because a wrong delivery address costs money; and its warehouse management system demands availability, because every hour of downtime stops trucks.

Balancing prevention, detection and correction

ITIL emphasizes that information security management must balance three kinds of activity. Prevention stops security incidents from happening, for example through access controls, patching and staff training. Detection finds incidents quickly when prevention fails, for example through monitoring, logging and alerts. Correction recovers from incidents and limits damage, for example through incident response, backups and restoration. No organization can prevent everything, so investment only in prevention leaves it blind and slow when something does go wrong.

Security also has to be balanced against other goals. Controls that are too strict make work so hard that people find workarounds, such as writing passwords down or using personal file-sharing services. ITIL encourages organizations to design controls that are proportionate to risk and that support, rather than obstruct, the work. The guiding principle "keep it simple and practical" applies directly.

Policies, risk and controls

Information security management is usually anchored in an information security policy approved by senior leadership, supported by more specific policies and standards, such as acceptable use, access control, cryptography, supplier security and incident response. Policies express what the organization intends; controls are the measures that put policy into effect.

Controls are chosen through risk assessment. A risk is a possible event that could cause harm or loss. Risk assessment identifies assets and threats, estimates the likelihood and impact of each risk, and compares the result with the organization's risk appetite. Risks above appetite are treated: reduced through controls, transferred through insurance or contracts, avoided by stopping an activity, or accepted with management approval. Controls can be classified by what they do, such as preventive, detective or corrective, and by their nature, such as technical (encryption), administrative (policies and training) or physical (locks and badges).

# A simple risk register: score likelihood x impact and compare with risk appetite
risks = [
    # risk, likelihood (1-5), impact (1-5), control in place
    ("Phishing leads to account takeover", 4, 4, "MFA for all staff"),
    ("Ransomware on warehouse servers", 3, 5, "EDR, offline backups"),
    ("Supplier breach exposes customer data", 2, 4, "Contract clauses, SOC 2 review"),
    ("Lost unencrypted laptop", 2, 3, "Full-disk encryption"),
    ("Unauthorized change to carrier rates", 2, 4, "Change control, logging"),
    ("Server room power failure", 1, 5, "UPS and generator"),
]
appetite = 10      # scores above this need treatment beyond current controls
print(f"{'risk':<40}{'L':>3}{'I':>3}{'score':>7}  decision")
for r, l, i, ctrl in sorted(risks, key=lambda x: -x[1] * x[2]):
    s = l * i
    decision = "treat further" if s > appetite else "accept and monitor"
    print(f"{r:<40}{l:>3}{i:>3}{s:>7}  {decision}  [{ctrl}]")

risk                                      L  I  score  decision
Phishing leads to account takeover        4  4     16  treat further  [MFA for all staff]
Ransomware on warehouse servers           3  5     15  treat further  [EDR, offline backups]
Supplier breach exposes customer data     2  4      8  accept and monitor  [Contract clauses, SOC 2 review]
Unauthorized change to carrier rates      2  4      8  accept and monitor  [Change control, logging]
Lost unencrypted laptop                   2  3      6  accept and monitor  [Full-disk encryption]
Server room power failure                 1  5      5  accept and monitor  [UPS and generator]

The scores here are residual risks after current controls. Two risks remain above the appetite even with controls in place, which tells leadership where further investment or acceptance decisions are needed. Real risk assessments use clearer definitions for each score, and many organizations use frameworks such as ISO/IEC 27005 or NIST guidance to structure them.

Security in the other practices

Information security management cannot succeed as a separate function that reviews everything at the end. It works by building security into other practices. The table below shows how it connects with the practices in this course and in ITIL-140.

ITIL-140 lesson 1 explained that the word incident means something different in security: a security incident under NIST SP 800-61 Revision 3, published in April 2025, is an occurrence that jeopardizes the confidentiality, integrity or availability of information or systems, or violates security policies. The service desk and incident management must recognize such events and pass them to the security incident response process, which has its own procedures for evidence, containment and notification.

Identity and access

Access management, a practice in its own right in some frameworks and part of information security management in ITIL 4, ensures that people have the access they need and no more. Key ideas are least privilege, giving each user only the access required for their role; segregation of duties, ensuring no single person controls all steps of a sensitive process; joiner, mover and leaver processes that grant, change and remove access promptly as people's roles change; and periodic access reviews in which managers confirm that their staff's access is still appropriate. Multi-factor authentication, which requires something you know plus something you have or are, is now a baseline control for remote access and privileged accounts.

Frameworks and standards

Several frameworks help organizations structure information security. ISO/IEC 27001 specifies requirements for an information security management system, and ISO/IEC 27002 provides a catalogue of controls; the current editions date from 2022. The NIST Cybersecurity Framework 2.0, released in February 2024, organizes security outcomes into six functions: govern, identify, protect, detect, respond and recover. The CIS Critical Security Controls give a prioritized list of practical safeguards, starting with inventories of assets and software. ITIL does not replace these frameworks; it shows how security fits into the service value system and works alongside the other practices.

Privacy and legal obligations

Information security supports privacy. In Canada, PIPEDA requires organizations to protect personal information with security safeguards appropriate to its sensitivity and to report breaches of security safeguards that create a real risk of significant harm to the Privacy Commissioner and to affected individuals. Quebec's Law 25 adds obligations such as confidentiality incident registers and privacy impact assessments. Provincial laws cover the public sector and health information. Bill C-8 received royal assent in June 2026, enacting the Critical Cyber Systems Protection Act for designated operators in federally regulated sectors such as telecommunications, banking, energy and transport; its obligations take effect as operators are designated and regulations are made, so check the current status. ITIL-140 lesson 4 mapped breach reporting obligations in more detail.

Service managers do not need to be privacy lawyers, but they need to know which services handle personal information, who is responsible for privacy decisions and how to escalate potential breaches quickly.

Culture and awareness

Most security incidents involve human actions: clicking a phishing link, misconfiguring a cloud storage bucket, reusing a password or sending data to the wrong person. Technology controls help, but people remain the first line of defence. Effective awareness programmes are short, frequent, relevant to people's actual work and free of blame. Encouraging staff to report suspicious emails, and thanking them when they do, turns every employee into a sensor. Punishing people who report their own mistakes teaches everyone to hide them.

Measuring information security

Measures for information security management include the share of critical vulnerabilities patched within agreed times; the share of accounts with multi-factor authentication; access review completion and findings; phishing report rates and simulated phishing click rates; time to detect and contain security incidents; audit findings closed on time; and the share of critical suppliers with current security assurance. As with service levels, distributions matter more than averages: a mean patch time of ten days can hide a few critical systems left unpatched for months.

# Patch compliance: share of critical vulnerabilities fixed within target, and the slowest cases
import random, statistics
random.seed(1141)
target_days = 14
# days to patch for 300 critical findings: most quick, a long tail of hard-to-patch systems
days = [round(random.expovariate(1 / 6)) for _ in range(270)] + [random.randint(30, 120) for _ in range(30)]
within = sum(1 for d in days if d <= target_days) / len(days) * 100
q = statistics.quantiles(days, n=20)
print(f"findings: {len(days)}   mean days to patch: {statistics.mean(days):.1f}   median: {statistics.median(days):.0f}")
print(f"within {target_days} days: {within:.1f} %")
print(f"90th percentile: {q[17]:.0f} days   95th percentile: {q[18]:.0f} days   max: {max(days)} days")
print("over 60 days:", sum(1 for d in days if d > 60), "findings need risk acceptance or a fix plan")

findings: 300   mean days to patch: 13.4   median: 6
within 14 days: 82.0 %
90th percentile: 31 days   95th percentile: 73 days   max: 119 days
over 60 days: 22 findings need risk acceptance or a fix plan

The mean looks reasonable, but the tail tells a different story: a group of findings has stayed open for months. Those are often the systems that are hardest to patch, such as legacy warehouse controllers, and they need specific plans, compensating controls or formal risk acceptance by the right level of management.