Understanding IT Security

Introduction

IT Security is the discipline of protecting information technology systems, applications, services, and information against unauthorized access, misuse, disruption, modification, and destruction. It includes the principles, policies, governance structures, risk management processes, security controls, technologies, platforms, and practices required to protect IT resources and ensure their secure and reliable operation.

IT Security applies wherever information technology is used, including personal computing environments, businesses, government institutions, educational establishments, healthcare, financial services, and critical infrastructure. Its scope covers the protection of hardware, software, networks, applications, data, and IT services throughout their lifecycle.

The primary objectives of IT Security are to preserve the Confidentiality, Integrity, and Availability (CIA) of IT resources. Confidentiality ensures that information is accessible only to authorized entities; integrity protects information and systems against unauthorized or improper modification; and availability ensures that systems, services, and information remain accessible when required.

IT Security extends beyond implementing technical safeguards. It includes establishing security policies and standards, defining responsibilities, managing risks, overseeing security controls, and integrating security into IT planning, implementation, operation, and maintenance. Practices such as asset management, change management, configuration management, vulnerability management, and service continuity help maintain security throughout the IT lifecycle.

The objective of IT Security is to protect IT resources, reduce security risks, maintain reliable service delivery, and safeguard information. Achieving these objectives requires a coordinated approach that combines governance, risk management, security controls, technologies, platforms, operational practices, and continual improvement.

What Is Information Technology (IT)?

Information Technology (IT) refers to the use of computing and communication technologies to collect, process, store, retrieve, and exchange information. It encompasses computing devices, software, data, storage systems, networks, platforms, and related services that enable information to be handled electronically.

IT is not limited to computers or software individually. It encompasses the interconnected technologies, systems, and services that enable information to flow, support digital activities, and make computing resources available to users and applications.

In an increasingly digitized world, IT serves as the foundation for how people work, communicate, access information, and use digital services. It enables enterprises to conduct business, automate processes, manage operations, and deliver products and services. It also supports critical infrastructure, including energy, transportation, telecommunications, healthcare, and financial services, where the availability and reliability of IT systems are essential to daily operations and service delivery.

IT enables end users like employees, consumers, professionals, and other individuals to access the systems, applications, information, and services they need to perform their activities. Examples of IT resources include personal computers, enterprise servers, business applications, databases, communication networks, data centers, virtualized platforms, and cloud computing services.

By connecting people, information, computing resources, and services, IT enables digital operations across personal, commercial, industrial, and public environments. It supports productivity, decision-making, communication, service delivery, and the efficient functioning of enterprises and critical infrastructure.

Elements of IT

Information Technology can be understood through five fundamental elements: computing, data, processing, storage, and communication. These elements describe the basic capabilities involved in handling information through computing systems.

Computing

Computing refers to the execution of instructions and computational operations using computing resources. Processors and other computing components perform arithmetic operations, logical comparisons, and programmed instructions.

Computing capabilities are found in devices ranging from personal computers and smartphones to enterprise servers and large-scale computing platforms.

Data

Data consists of recorded facts, values, observations, transactions, and other representations of entities or events. It can take many forms, including numbers, text, images, audio, and video.

Data serves as an input to computing systems. It can be processed, stored, retrieved, and exchanged to support applications, business activities, and decision-making.

Processing

Processing involves performing operations on data according to instructions, rules, or algorithms. These operations include calculations, sorting, validation, filtering, classification, and transformation.

For example, a business application may process transaction records to calculate totals, validate entries, or produce a report.

Computing and processing are closely related. Processing is generally performed through computing resources, but they are treated separately here to distinguish the capability to execute instructions from the operations performed on data.

Storage

Storage refers to retaining data, programs, instructions, and processing results for subsequent use. Storage can be temporary or persistent.

Temporary storage, such as working memory, supports active processing. Persistent storage, including solid-state drives, hard disk drives, and database storage systems, retains information for later access.

Communication

Communication involves transferring data and information between devices, systems, applications, and users. It relies on communication technologies, transmission media, networks, and protocols.

Communication enables systems to exchange information locally and across geographically distributed locations, supporting services such as email, web applications, file transfers, and enterprise system integration.

Evolution and Purpose of IT

Information Technology has evolved from specialized computing systems used primarily for calculations and record-keeping into interconnected computing environments that support complex organizational and personal activities.

Early computing systems focused on mathematical calculations, scientific work, and large-scale data processing. Personal computers expanded computing access to individuals and businesses. Networking and the internet enabled information exchange across connected systems, while enterprise applications integrated business processes across departments.

virtualization and cloud computing introduced more flexible ways to provision and manage computing resources. Distributed computing enables workloads and services to operate across multiple interconnected systems.

The principal purposes of IT include:

• Information management: Collecting, organizing, storing, and retrieving information.
• Process automation: Executing repetitive or rule-based tasks with reduced manual effort.
• Communication and collaboration: Enabling information exchange between people, applications, and organizations.
• Business enablement: Supporting transactions, operations, customer services, and organizational decision-making.
• Resource utilisation: Providing computing, storage, and communication capabilities to meet operational requirements.
• Service delivery: Supporting the applications and digital services used by individuals and organizations.

IT enables organizations to use information and computing resources to achieve operational and business objectives.

IT Environment

An IT environment is the collection of computing systems, software, data resources, communication technologies, and supporting platforms that work together to process information and deliver IT services.

An IT environment may be simple, such as a personal computer connected to a home network, or complex, such as an enterprise environment spanning endpoints, servers, data centers, virtualised infrastructure, databases, and cloud services.

The components of an IT environment have different roles but depend on one another. Endpoints provide user access, servers deliver shared services, networks connect systems, software implements functionality, and databases manage persistent information. IT services and operations coordinate the delivery, maintenance, and support of these capabilities.

Endpoint Computing

Endpoint computing refers to computing performed through devices that users interact with directly or that serve as points of access to applications and services.

Common endpoint devices include:

• Desktop computers and laptops
• Smartphones and tablets
• Thin clients and virtual desktop terminals
• Workstations used for specialized technical tasks

Endpoints run operating systems and applications, process user input, display information, and communicate with other systems. In organizations, they commonly connect to enterprise networks and centralised services to access applications, files, and shared resources.

Endpoint computing supports individual productivity, business applications, communication, remote work, and access to organizational information.

Server Computing

Server computing involves systems that provide resources, applications, data, or services to other systems and users over a network.

Servers may operate as physical machines or as virtual machines hosted on shared computing infrastructure. Their functions depend on the services they provide.

Examples include:

• Application servers: Execute application logic and business functions.
• Web servers: Deliver web content and handle HTTP or HTTPS requests.
• File servers: Provide centralised file storage and access.
• Database servers: Host database management systems and process data requests.
• Directory servers: Maintain directory information used for identity and resource lookup.

Server computing enables centralised service delivery, resource sharing, and administration across multiple users and applications.

Networks and Communication

Networks connect computing systems and enable them to exchange data and access shared resources. Communication technologies establish the pathways through which systems, applications, and users interact.

Common network types include:

• Local Area Network (LAN): Connects devices within a limited area, such as an office or building.
• Wide Area Network (WAN): Connects systems and networks across geographically separated locations.
• Wireless Local Area Network (WLAN): Provides network connectivity using wireless technologies.
• The Internet: A global interconnection of networks that enables communication and access to services.
• Virtual Private Network (VPN): Establishes a logical private connection across an underlying network.

Network infrastructure includes switches, routers, wireless access points, transmission links, and other communication components. Network protocols define how data is addressed, transmitted, received, and interpreted.

Networks provide the connectivity required for distributed applications, remote access, file sharing, business communication, and access to cloud services.

Data Centers

A data center is a facility that houses computing, storage, and networking resources used to operate IT systems and services.

Data centers contain physical infrastructure such as servers, storage systems, network equipment, racks, power distribution, cooling systems, and environmental monitoring facilities.

They may support enterprise applications, databases, internal business services, internet-facing platforms, and virtualization infrastructure.

Data centers require suitable power, cooling, physical space, connectivity, and operational management to maintain the availability and performance of the systems they host.

organizations may operate their own data centers, use colocation facilities, or consume infrastructure services provided by external operators.

virtualization

virtualization is a technology that abstracts computing resources from their underlying physical hardware, allowing multiple logical computing instances or resources to operate on shared infrastructure.

Common forms of virtualization include:

• Server virtualization: Runs multiple virtual machines on a physical host.
• Desktop virtualization: Provides desktop computing sessions from centralised infrastructure.
• Storage virtualization: Presents storage resources as logical pools independent of individual physical devices.
• Network virtualization: Creates logical network resources over physical network infrastructure.

A hypervisor is a software layer that enables virtual machines to share physical computing resources. Each virtual machine can run its own operating system and applications within its allocated resources.

Virtualisation improves resource utilisation, supports workload isolation, and simplifies the provisioning and management of computing systems.

Cloud Computing

Cloud computing provides on-demand access to computing resources and services over a network. Resources can be provisioned and released as requirements change, with charging commonly based on usage or subscription arrangements.

Cloud services are generally grouped into three service models:

• Infrastructure as a Service (IaaS): Provides computing, storage, and networking resources.
• Platform as a Service (PaaS): Provides managed platforms for developing, deploying, and running applications.
• Software as a Service (SaaS): Provides applications that users access through a network, often through a web browser or client application.

Cloud deployment models include public cloud, private cloud, hybrid cloud, and community cloud.

Cloud computing allows organizations to obtain resources without necessarily owning and maintaining all the underlying physical infrastructure. The responsibilities of the provider and customer vary according to the service model and contractual arrangement.

Distributed Computing

Distributed computing involves multiple interconnected computing systems working together to execute tasks, process data, or deliver services.

Instead of relying on a single computer, a distributed application may divide its workload among several systems. These systems communicate over networks and coordinate their activities to achieve a common objective.

Examples include distributed databases, clustered computing systems, content delivery networks, and applications composed of services running across multiple hosts.

Distributed computing can improve scalability, support geographic distribution, and provide resilience against certain system failures. However, it also introduces challenges involving network latency, coordination, data consistency, and partial failures.

Software and Applications

Software consists of programs, instructions, and related components that direct computing systems to perform specific tasks. Applications use computing resources to provide functions for individuals, businesses, and other systems.

Software can be broadly grouped into the following categories:

• System software: Operating systems, device drivers, and utilities that manage hardware and provide a foundation for other software.
• Business and enterprise applications: Systems supporting functions such as finance, human resources, customer relationship management, and enterprise resource planning.
• Web applications: Applications accessed through web browsers or web-based interfaces.
• Mobile applications: Applications designed for smartphones, tablets, and other mobile devices.
• Middleware and integration software: Components that facilitate communication and data exchange between applications and systems.

Software and applications may run on endpoints, servers, virtual machines, cloud platforms, or combinations of these resources. They provide the functionality through which users interact with IT systems and organizations conduct their activities.

Databases and Data Management Systems

Databases organize and retain data so that it can be stored, retrieved, updated, and managed efficiently. They support applications that require persistent access to information, including customer records, financial transactions, inventory, and operational data.

A Database Management System (DBMS) provides capabilities for defining, storing, querying, updating, and administering databases.

Common database categories include:

• Relational databases: organize data into tables with defined relationships and commonly use Structured Query Language (SQL).
• Document databases: Store data as structured documents, often using flexible schemas.
• Key-value databases: Store information as key-value pairs.
• Graph databases: Represent entities and their relationships as nodes and edges.
• Time-series databases: Manage data associated with time-based measurements and events.

Data management also includes data integration, data quality, metadata management, and the movement of data between systems. These capabilities help organizations maintain useful, consistent, and accessible information for applications and business processes.

Database selection depends on data structure, workload, consistency requirements, scale, performance, and operational needs.

IT Services and Operations

IT services and operations encompass the activities required to deliver, operate, maintain, and support the computing systems, applications, and infrastructure within an IT environment. They help ensure that technology resources remain available, perform as expected, and support organizational requirements.

These activities include IT service delivery, IT service management (ITSM), IT operations and user support, infrastructure and asset management, configuration and change management, incident and problem management, monitoring and performance management, backup and recovery, service continuity and availability, capacity planning, automation and orchestration, service-level management, and vendor and service provider management.

Together, these functions support the reliable operation and ongoing management of IT resources and services. Their implementation varies according to the organization’s size, operating model, technology environment, and business requirements.

What is IT Security

Objectives of IT Security

IT Security aims to protect information technology systems, applications, services, and information resources from threats, vulnerabilities, unauthorized access, misuse, disruption, and destruction. Its objectives include protecting information, maintaining confidentiality, integrity, and availability, reducing security risks, supporting business operations, and ensuring compliance with applicable policies, standards, and regulations.

Scope of IT Security

People

People include employees, contractors, administrators, IT professionals, third-party personnel, and other individuals who interact with an organization’s IT environment. IT Security establishes responsibilities, access requirements, and security awareness practices to reduce risks arising from human error, misuse, and unauthorized activities.

Processes

Processes are the policies, procedures, workflows, and operational activities used to manage and protect IT resources. IT Security integrates security requirements into IT governance, change management, incident management, access management, vulnerability remediation, and other IT processes to ensure that security responsibilities are consistently performed.

Data

Data includes the information an organization creates, processes, stores, transmits, and receives through its IT environment. IT Security protects data against unauthorized access, disclosure, modification, destruction, and loss through appropriate access controls, encryption, data protection measures, backup practices, and monitoring.

Platforms

Platforms include the technology systems and environments that support IT services, applications, and data processing. These include endpoints, servers, networks, databases, virtualization environments, cloud platforms, and other computing resources. IT Security establishes and monitors security requirements to protect these platforms against vulnerabilities, unauthorized access, misconfiguration, and other security threats.

Confidentiality, Integrity and Availability

The Confidentiality, Integrity, and Availability (CIA) Triad represents three fundamental security objectives.

Confidentiality

Confidentiality ensures that information is accessible only to authorized individuals, systems, and processes. It protects sensitive information from unauthorized disclosure through measures such as access controls, authentication, encryption, and data classification.

Integrity

Integrity ensures that information remains accurate, complete, consistent, and protected against unauthorized modification or destruction. Security measures such as access restrictions, change management, validation, and integrity monitoring help maintain the reliability of information and IT resources.

Availability

Availability ensures that authorized users can access information, systems, applications, and services when required. Measures such as redundancy, capacity management, backup and recovery, fault tolerance, and protection against service disruptions help maintain availability.

Principles of IT Security

IT Security principles provide the foundation for establishing security requirements, selecting appropriate controls, and protecting IT resources. They guide how security is governed, implemented, and maintained across the IT environment.

Key principles include:

Least Privilege

Least privilege ensures that users, systems, and processes receive only the permissions necessary to perform their assigned functions. This limits unnecessary access and reduces the risk of unauthorized activities and misuse of privileges.

Need to Know

Need to know ensures that access to information is granted only when it is required for an authorized purpose. This helps prevent unnecessary exposure of sensitive information.

Separation of Duties

Separation of duties divides sensitive tasks and responsibilities among multiple individuals or roles to reduce the risk of errors, misuse, and fraud. It helps prevent a single individual from having excessive control over critical activities.

Defense in Depth

Defense in depth applies multiple layers of security controls so that the failure of one control does not automatically compromise the entire environment. These layers work together to reduce the likelihood and impact of security incidents.

Secure by Design

Secure by design incorporates security requirements into the design and architecture of IT systems, applications, and services. This helps address security risks early rather than relying solely on controls added after implementation.

Default Deny

Default deny ensures that access is denied unless it has been explicitly authorized. This reduces the possibility of unintended access to IT resources.

Zero Trust

Zero Trust ensures that users, devices, applications, and systems are not implicitly trusted based on their location or network access. It requires appropriate verification, enforces least-privilege access, and evaluates access requests based on identity, device security, context, and risk.

Accountability

Accountability ensures that activities can be attributed to the responsible users, systems, or processes. Logging, monitoring, and audit trails help establish responsibility and support investigations into security incidents.

Risk-Based Security

Risk-based security prioritizes security measures according to the likelihood and potential impact of threats. It helps direct resources toward the risks that matter most to the organization.

Continuous Monitoring

Continuous monitoring involves observing IT resources and security controls to identify suspicious activities, weaknesses, and changes in risk. It supports timely detection and response to potential security issues.

Resilience

Resilience ensures that IT systems and services can withstand disruptions, recover from failures, and maintain essential operations. Measures such as fault tolerance, redundancy, disaster recovery, backup and restoration, and continuity planning help maintain or restore IT services during and after disruptions.

IT Security Governance

IT Security Governance defines how security requirements are established, agreed upon, implemented, monitored, and maintained across the IT environment. It operates within the broader framework of Cybersecurity Governance, bringing together cybersecurity leadership, IT management, specialist security teams, IT delivery and operations teams, and Governance, Risk, and Compliance (GRC) to ensure that security requirements are integrated into IT services, systems, and operations.

The CISO and cybersecurity governance team establish cybersecurity policies, risk requirements, control expectations, and compliance obligations in collaboration with the IT Head and other relevant stakeholders. Once requirements are agreed upon, the IT organization implements and operates the applicable controls through the IT Security Lead and the teams responsible for IT infrastructure, networks, endpoints, cloud environments, identity services, applications, and IT operations.

The CISO function provides governance direction and oversight, while IT management is responsible for implementing and maintaining the agreed requirements within the IT environment. The IT Security Lead coordinates implementation across the relevant teams, and GRC supports governance, risk management, compliance monitoring, and reporting. This collaborative model connects cybersecurity governance with the practical delivery and operation of IT security.

IT Security and Cybersecurity Leadership

IT Security Governance requires collaboration between cybersecurity leadership and IT management. Their responsibilities should be clearly defined so that security requirements are agreed upon, implementation is assigned to the appropriate teams, and significant risks and control deficiencies receive appropriate attention.

CISO

The Chief Information Security Officer (CISO) provides cybersecurity leadership and oversees the organization’s cybersecurity governance arrangements. The CISO works with IT leadership to establish security expectations, address significant risks, and ensure that cybersecurity requirements align with business objectives, risk tolerance, and applicable obligations.

The CISO also reviews significant security issues, evaluates the effectiveness of governance arrangements, and escalates material risks to the appropriate management or executive authority.

IT Head

The IT Head is responsible for ensuring that the IT organization implements and maintains the agreed security requirements. This includes allocating resources, assigning responsibilities, incorporating security into IT projects and operations, and ensuring that IT teams address security deficiencies.

The IT Head collaborates with the CISO to resolve competing priorities, assess implementation constraints, and determine appropriate actions when IT requirements, business needs, and security expectations conflict.

IT Security Lead

The IT Security Lead coordinates the implementation of IT security requirements across the IT environment. The role translates agreed security requirements into implementation activities and works with specialist security teams, IT delivery teams, and IT operations teams to ensure that the applicable controls are implemented and maintained.

The IT Security Lead monitors implementation progress, identifies control gaps, coordinates remediation, and reports relevant security performance and operational issues to IT management and the cybersecurity governance function.

Roles and Responsibilities

IT Security Governance depends on cooperation between specialist security teams and the teams responsible for delivering and operating IT services. Each team implements and maintains security controls within its assigned area, following the agreed requirements and established operational processes.

Endpoint Security Team

The Endpoint Security Team implements and maintains security controls for end-user devices, workstations, laptops, and other supported endpoints. Responsibilities may include endpoint protection, endpoint detection and response, device security configurations, policy enforcement, vulnerability remediation, and monitoring endpoint security status.

Network Security Team

The Network Security Team implements and maintains security controls that protect network infrastructure and communications. Responsibilities may include firewall management, network segmentation, secure network configurations, network access controls, and monitoring network security events.

The team coordinates with infrastructure, cloud, and operations teams to ensure that applicable network security requirements are implemented across the IT environment.

Cloud Security Team

The Cloud Security Team implements and maintains security controls for cloud environments. Responsibilities may include cloud security configurations, cloud identity and access controls, workload protection, security posture monitoring, and remediation of cloud security findings.

The team collaborates with cloud platform owners, application teams, IT operations, and the IT Security Lead to maintain compliance with agreed security requirements.

Infrastructure and Platform Teams

Infrastructure and platform teams manage the security of the underlying IT infrastructure, including servers, operating systems, virtualization platforms, storage, and related services.

Their responsibilities include implementing approved security configurations, applying patches, remediating vulnerabilities, maintaining system hardening, and ensuring that infrastructure operations follow applicable security requirements.

Identity and Access Security Team

The Identity and Access Security Team implements and operates identity-related security controls. Responsibilities may include user access provisioning and deprovisioning, authentication controls, access reviews, privileged access management, and enforcement of approved access policies.

The team works with IT management, application owners, and the IT Security Lead to ensure that access is granted, modified, reviewed, and revoked in accordance with established requirements.

IT Delivery Teams

IT delivery teams incorporate security requirements into the design, development, deployment, and modification of IT systems and services. They work with the IT Security Lead and relevant specialist security teams to identify security requirements, implement applicable controls, address security findings, and follow established change-management processes.

IT Operations Teams

IT operations teams maintain the security of systems and services throughout their operational lifecycle. Responsibilities may include secure configuration maintenance, patching, backup execution, operational monitoring, approved change implementation, incident escalation, and maintenance of operational records.

They coordinate with specialist security teams to address security issues and maintain the required controls.

Application and Service Owners

Application and service owners ensure that the systems and services under their responsibility meet applicable security requirements. They coordinate with delivery teams, IT operations, and specialist security teams to address risks, implement controls, maintain relevant documentation, and resolve identified deficiencies.

Governance, Risk, and Compliance (GRC) Team

The GRC team supports the implementation and oversight of cybersecurity governance requirements in collaboration with the CISO, IT Security Lead, and IT management.

Its responsibilities may include coordinating risk assessments, maintaining governance and compliance requirements, conducting or coordinating compliance assessments, reviewing control evidence, monitoring remediation activities, and preparing risk and compliance reports.

Although GRC may report directly to the CISO, its responsibilities extend across the IT organization. The team works with IT stakeholders to assess compliance with agreed requirements, identify gaps, and escalate significant issues through established governance channels.

The precise allocation of responsibilities varies by organization. Some teams may be combined or operate under different reporting structures. Regardless of the structure, ownership, implementation responsibilities, and governance oversight should be clearly defined.

Security Policies, Standards, Baselines, Procedures, and Guidelines

Security policies, standards, baselines, procedures, and guidelines provide the documented direction and requirements used to govern IT security.

The CISO and cybersecurity governance team establish or oversee applicable security policies and governance requirements in collaboration with IT stakeholders. IT management and the IT Security Lead help translate these requirements into practical implementation measures, configuration standards, operational procedures, and supporting guidelines.

These artefacts serve different purposes:

Security Policies

Security policies define the organization’s security objectives, principles, and mandatory requirements. They establish management expectations for protecting IT systems, services, and information and provide direction for developing more detailed security standards and procedures.

Security Standards

Security standards specify mandatory security requirements that IT systems, services, technologies, and processes must meet. They translate policy requirements into defined criteria, helping IT teams implement security consistently across the organization.

Security Baselines

Security baselines establish minimum approved security configurations for systems, platforms, and devices. They may define requirements for system hardening, secure configurations, enabled services, logging, and other settings needed to maintain an acceptable security posture.

Security Procedures

Security procedures describe the steps that teams must follow to perform specific security-related activities. They help ensure that operational tasks, such as applying security patches, reviewing access permissions, and responding to security alerts, are performed consistently and in accordance with established requirements.

Security Guidelines

Security guidelines provide recommendations and practical advice for implementing security requirements. Unlike mandatory standards, guidelines generally allow flexibility where appropriate, helping IT teams select suitable approaches based on their technical environments and operational needs.

IT teams follow the applicable requirements and procedures within their areas of responsibility. Where technical or operational requirements cannot be met, the responsible teams work with IT management and the cybersecurity governance function to assess the gap, document the associated risk, and follow the established exception or risk-acceptance process.

Implementation of Security Requirements

Security requirements must be translated into practical measures across IT projects, systems, services, and operational activities.

The CISO and cybersecurity governance team establish the applicable requirements in collaboration with IT management. The IT Head ensures that responsibilities and resources are assigned, while the IT Security Lead coordinates implementation with the relevant specialist security teams and IT delivery and operations teams.

Implementation may involve configuring security controls, applying approved baselines, integrating security into IT projects, updating operational procedures, addressing vulnerabilities, or strengthening access controls.

Where implementation gaps arise, the responsible IT team assesses the issue and works with the IT Security Lead and IT management to determine corrective actions. Significant risks, unresolved deficiencies, and exceptions are escalated to the appropriate governance or management authority.

This approach ensures that security requirements are not limited to documented policies but are incorporated into the delivery and operation of IT services.

IT Security Processes and Procedures

IT security requirements must be incorporated into the processes used to manage IT systems and services throughout their lifecycle.

Examples include:

• User access provisioning, modification, and revocation.
• Secure system configuration and hardening.
• Vulnerability identification and remediation.
• Security patch assessment and deployment.
• IT change management.
• Backup and recovery operations.
• Security incident escalation and coordination.
• System and service onboarding and decommissioning.

The IT Security Lead coordinates the integration of applicable security requirements into these processes. IT process owners and operational teams maintain and execute the procedures relevant to their responsibilities, while the cybersecurity governance function provides oversight where required.

IT Security Service-Level Agreements (SLAs)

IT Security Service-Level Agreements (SLAs) for security incidents define agreed timeframes for detecting, acknowledging, assessing, escalating, responding to, and containing reported security incidents. These commitments help ensure that incidents are handled according to their severity, potential business impact, and associated security risks.

The CISO and cybersecurity governance team collaborate with the IT Head and IT Security Lead to establish incident response expectations. The IT Security Lead coordinates implementation with the relevant security and IT operations teams, ensuring that responsibilities, escalation paths, performance metrics, and reporting requirements are clearly defined.

The SLA should specify the following:

• Incident detection: The target time for detecting a security incident through security monitoring, alerts, analysis, or incident reporting.
• Incident acknowledgement: The target time for the responsible team to acknowledge a detected incident or received incident report.
• Initial assessment: The target time for assessing the incident’s severity, scope, and potential impact.
• Escalation: The timeframe for notifying appropriate security leadership, IT management, and other stakeholders according to incident severity.
• Response and containment: The target time for initiating appropriate response activities and containing the incident to limit its impact.
• Recovery coordination: The expected timeframe for coordinating recovery activities with the responsible IT teams, where applicable.
• Incident reporting: The timeframe for communicating incident status, significant developments, and closure details to relevant stakeholders.

Security Incident Response Metrics

Organizations can use defined performance metrics to measure incident response efficiency and assess performance against established SLA targets. The following are commonly used security incident response metrics; however, the metrics adopted may vary depending on organizational requirements, incident management practices, security capabilities, and the SLAs established.

Mean Time to Detect (MTTD)

Measures the average time taken to detect a security incident from its defined starting point, such as the incident’s occurrence or initial observable activity. The organization should specify the measurement starting point because it affects the reported result.

Mean Time to Acknowledge (MTTA)

Measures the average time between an incident alert or report being generated and the responsible team acknowledging it. This helps assess whether security alerts are being recognized within the agreed timeframe.

Mean Time to Respond (MTTR)

Measures the average time taken to initiate an appropriate response after an incident is detected or acknowledged, according to the organization’s defined measurement criteria. Because MTTR can have different meanings across organizations, the SLA should explicitly define the metric and its start and end points.

Mean Time to Contain (MTTC)

Measures the average time taken to contain a security incident after it has been identified or declared. Containment activities may include isolating affected endpoints, restricting compromised accounts, or blocking malicious network traffic to prevent further impact.

Mean Time to Recover

Measures the average time required to restore affected systems or services to an acceptable operational state following an incident. Recovery may involve restoring systems, validating their integrity, and confirming that appropriate security controls are functioning. The organization should define the measurement criteria and distinguish recovery from incident resolution.

Incident response SLAs should define targets according to incident severity and business impact. For example, a critical ransomware incident affecting essential business services would require more urgent escalation and response than a low-impact security event.

The organization should establish specific targets based on risk assessments, business requirements, regulatory obligations, and operational capabilities. The SLA should also specify how response times are measured, when measurement begins and ends, who owns each activity, and how missed targets are escalated.

The IT Security Lead coordinates performance monitoring and works with the relevant security and IT operations teams to identify missed targets and recurring delays. IT management addresses operational issues, while the CISO and Governance, Risk, and Compliance (GRC) team review significant incidents, performance trends, and unresolved risks in accordance with established governance arrangements.

IT Security Control Implementation and Management

IT security controls are implemented and maintained by the teams responsible for the systems, services, and processes being protected. Depending on the requirements, controls may involve technical safeguards, operational procedures, administrative measures, or a combination of these.

The IT Security Lead coordinates control implementation across the IT environment and works with specialist security teams to identify gaps and support remediation. IT management ensures that the necessary responsibilities and resources are assigned, while the CISO and cybersecurity governance team oversee compliance with agreed requirements and review significant residual risks.

Control ownership, implementation responsibility, and oversight should be clearly defined so that controls are not merely documented but are implemented, operated, and maintained effectively.

IT Security Compliance and Evidence Management

IT teams maintain records and evidence demonstrating that applicable security requirements and controls have been implemented and are operating as intended. Evidence may include access reviews, configuration records, vulnerability remediation records, change approvals, backup reports, and other relevant operational documentation.

The IT Security Lead coordinates the collection and review of security implementation evidence. The GRC team assesses compliance against applicable requirements and coordinates the handling of identified gaps with IT management and the responsible teams.

Where deficiencies are identified, the relevant stakeholders document the issue, assess its significance, assign remediation responsibilities, and track corrective actions. Significant or unresolved issues are escalated through established governance channels.

IT Security Performance Monitoring and Reporting

IT Security Governance requires regular monitoring of implementation progress, control performance, compliance status, and outstanding risks.

IT teams provide operational information and metrics, while the IT Security Lead consolidates implementation status and identifies significant issues. IT management addresses operational gaps and resource constraints, and the CISO and GRC team review relevant information to assess risk exposure, compliance, and the effectiveness of the governance arrangements.

Performance reporting may include control implementation status, outstanding vulnerabilities, overdue remediation activities, incident response performance, compliance gaps, and unresolved security risks. The metrics selected should reflect the organization’s requirements, priorities, and risk exposure.

Significant risks, recurring control deficiencies, and unresolved exceptions are escalated to the appropriate management or governance authority. Reporting should support decisions and corrective action rather than simply measure activity.

IT Risk Management

IT Risk Management addresses risks arising from an organization’s IT systems, services, infrastructure, technology investments, and operational processes. It focuses on identifying, assessing, treating, and monitoring risks that could affect IT service delivery, system reliability, operational continuity, resource utilization, and business objectives.

IT Risk Management operates within the governance and oversight of Cybersecurity Risk Management, which establishes the approach for managing cybersecurity risks across the organization. IT teams typically implement remediation measures to address identified IT risks, while risk ownership, treatment decisions, and acceptance responsibilities are assigned according to the organization’s governance structure.

IT Risk Identification

IT Risk Identification is the process of recognizing and documenting events, conditions, and circumstances that could negatively affect IT systems, services, resources, operations, or business objectives.

Risk identification considers the organization’s IT environment, including infrastructure, applications, databases, cloud services, IT service providers, operational processes, and technology projects. It also examines dependencies between IT components and the business services they support.

Common methods of IT risk identification include:

IT Asset and Service Analysis

Identifying critical IT assets, systems, applications, and services whose failure, degradation, or unavailability could disrupt business operations.

Operational Process Analysis

Examining IT workflows, operational procedures, and service management processes to identify inefficiencies, weaknesses, dependencies, and potential points of failure.

Technology Lifecycle Analysis

Identifying risks associated with obsolete technologies, unsupported systems, ageing infrastructure, end-of-life products, and delayed technology upgrades.

Dependency Analysis

Evaluating dependencies on infrastructure components, software platforms, personnel, suppliers, cloud service providers, and external IT services.

Incident and Problem Analysis

Reviewing previous IT incidents, recurring service disruptions, performance issues, and operational failures to identify underlying causes and recurring risk patterns.

Project and Change Analysis

Identifying risks associated with IT implementations, system migrations, infrastructure changes, application deployments, and technology transformation initiatives.

Identified risks should be documented with information about their causes, potential events, affected systems or services, and possible business consequences. These records provide the foundation for subsequent risk assessment and treatment.

IT Risk Assessment

IT Risk Assessment is the process of evaluating identified IT risks to determine their likelihood, potential consequences, and significance to the organization.

The assessment considers how technology failures, operational weaknesses, resource limitations, or service disruptions could affect business processes, service commitments, productivity, costs, and organizational objectives.

IT Risk Assessment typically involves the following activities:

Likelihood Assessment

Estimating the probability or frequency of an IT risk event occurring based on historical incidents, operational experience, technology characteristics, and available evidence.

Impact Assessment

Evaluating the potential consequences of a risk event, including service downtime, financial losses, reduced productivity, missed service commitments, and disruption to business operations.

Inherent Risk Assessment

Evaluating the level of risk before considering the effect of existing controls or mitigation measures.

Existing Control Assessment

Examining existing operational procedures, service management practices, maintenance arrangements, redundancy measures, and other safeguards intended to manage the identified risk.

Residual Risk Assessment

Determining the level of risk remaining after considering existing controls and mitigation measures.

Risk Prioritization

Ranking risks according to their assessed significance, potential business impact, urgency, and alignment with the organization’s risk criteria.

Organizations may use qualitative assessments, quantitative analysis, or a combination of both. Qualitative assessments commonly use likelihood and impact ratings, while quantitative approaches may estimate financial losses, downtime costs, recovery expenses, or other measurable consequences.

The assessment results help management determine which risks require immediate action, which can be addressed through planned improvements, and which may be accepted within established risk tolerance.

IT Risk Treatment

IT Risk Treatment is the process of selecting and implementing appropriate measures to modify identified IT risks to an acceptable level.

Treatment decisions depend on the nature and significance of the risk, its potential business consequences, available options, implementation costs, and the organization’s risk tolerance.

Common IT risk treatment approaches include:

Risk Mitigation

Implementing measures to reduce the likelihood or impact of an IT risk.

Examples include introducing infrastructure redundancy, improving capacity planning, strengthening change management, and establishing preventive maintenance procedures.

Risk Avoidance

Discontinuing or not undertaking an activity when its associated risk is considered unacceptable.

For example, an organization may decide not to implement a technology that cannot meet its performance, compatibility, or operational requirements.

Risk Sharing

Distributing certain financial or operational consequences of an IT risk among multiple parties through contractual arrangements, outsourcing, partnerships, or other agreements.

For example, an organization may engage an external IT service provider to operate a service under agreed service-level commitments. The agreement can allocate responsibilities and certain consequences of service failure between the parties, although the organization may retain overall accountability for its business obligations.

Risk sharing does not necessarily eliminate the underlying risk or transfer all associated responsibilities to another party.

Risk Acceptance

Formally accepting a known risk when it falls within established risk tolerance or when additional treatment is not justified under the organization’s decision criteria.

Acceptance must be authorized by the designated risk owner or appropriate authority.

Risk treatment should be supported by a documented plan identifying the selected approach, required actions, responsible teams, resource requirements, target completion dates, and expected outcomes.

IT teams typically implement the technical and operational remediation measures assigned to them. The designated risk owner oversees the risk and treatment decisions, while the relevant governance function provides oversight where the risk falls within its remit.

After treatment measures are implemented, the remaining risk should be reassessed to determine whether it falls within acceptable limits. Risks that remain above established tolerance should be escalated to the appropriate authority.

IT Risk Monitoring and Reporting

IT Risk Monitoring and Reporting involves reviewing identified risks, tracking changes in their significance, monitoring treatment activities, and communicating relevant information to decision-makers.

IT risks can change as a result of technology upgrades, increasing workloads, changing business requirements, supplier performance, infrastructure failures, resource constraints, and changes in service delivery arrangements. Regular monitoring helps organizations identify these changes and respond before they cause significant disruption.

Key monitoring and reporting activities include:

Risk Register Maintenance

Maintaining an up-to-date record of identified risks, including their descriptions, ratings, owners, treatment plans, and current status.

IT Performance Monitoring

Monitoring service availability, system performance, capacity utilization, recurring failures, and other operational indicators that may reveal emerging risks.

Key Risk Indicator Monitoring

Tracking indicators that signal changes in risk exposure, such as repeated service interruptions, capacity constraints, increasing maintenance costs, or overdue technology upgrades.

Treatment Progress Tracking

Monitoring the implementation of agreed risk treatment measures against established milestones, responsibilities, and deadlines.

Residual Risk Review

Reassessing remaining risks when operational conditions, technology dependencies, business requirements, or existing controls change.

Risk Escalation

Escalating significant risks to the appropriate management authority when they exceed established thresholds, require additional resources, or cannot be managed within the existing team’s authority.

Management Reporting

Providing IT management and relevant governance stakeholders with information about significant risks, emerging trends, treatment progress, and decisions requiring attention.

Organizations may use risk registers, operational dashboards, service reports, key risk indicators, and management review meetings to support these activities.

Effective reporting enables decision-makers to understand the potential consequences of IT risks, evaluate treatment progress, and determine whether further action is necessary.

Risk Ownership and Acceptance

Risk Ownership and Acceptance establishes responsibility for managing identified IT risks and defines the authority required to decide whether a risk can be retained.

Risk Ownership

A risk owner is the individual or designated role responsible for ensuring that a particular risk is assessed, monitored, and managed appropriately. The risk owner is accountable for coordinating the response to the risk, even when remediation activities are delegated to technical or operational teams.

Depending on the organization’s governance structure, risk ownership may reside with an IT service owner, application owner, infrastructure manager, IT operations manager, technology project manager, or business process owner.

Risk owners are generally responsible for:

• Understanding the assigned risk and its potential business consequences.
• Ensuring that risk assessments are completed and reviewed when necessary.
• Coordinating the development and implementation of treatment plans.
• Monitoring the effectiveness and progress of treatment measures.
• Reporting significant changes in risk exposure.
• Escalating risks that exceed established tolerance or delegated authority.
• Obtaining appropriate approval when formal risk acceptance is required.

Risk ownership does not mean that one individual must implement every treatment measure. IT teams may be responsible for implementing technical and operational remediation, while risk owners retain responsibility for coordinating and overseeing the risk response.

Risk Acceptance

Risk Acceptance is a formal decision to retain a known risk after considering its potential consequences, existing measures, available treatment options, and alignment with organizational risk tolerance.

Acceptance should follow established approval procedures and be performed by an individual or authority with the appropriate decision-making power. IT teams responsible for remediation should not automatically be assumed to have the authority to accept the risks they are addressing.

A documented risk acceptance decision should identify the risk, its assessed level, the rationale for acceptance, the approving authority, any required conditions, and the date or circumstances for review.

Where an IT risk has cybersecurity implications, its acceptance must follow the organization’s established cybersecurity risk governance and approval arrangements.

Risk acceptance does not eliminate the risk or remove the need for monitoring. Accepted risks should be reassessed when operational conditions change, the risk exceeds established thresholds, or the acceptance period expires.

Distinguishing Risk Ownership from Risk Acceptance

Risk ownership concerns responsibility for managing a risk, whereas risk acceptance concerns the authorized decision to retain that risk. The risk owner may also have the authority to accept a risk, but some decisions require approval from a more senior management authority or a designated risk governance function.

This distinction ensures that IT risk decisions are documented, appropriately authorized, and aligned with organizational objectives.

IT Audit and Compliance

IT Audit and Compliance is a specialized application of the broader Audit and Compliance discipline, focusing on information technology systems, services, processes, and controls.

While the broader discipline covers audit and compliance across organizational functions and industries, IT Audit and Compliance addresses the requirements, risks, and controls associated specifically with the IT environment. It evaluates whether IT operations conform to applicable requirements and whether IT controls are appropriately designed, implemented, and operating effectively.

IT Audit and Compliance supports IT governance by providing assurance over IT controls, identifying control deficiencies, assessing compliance gaps, and helping management address identified issues. IT teams maintain and operate controls, compliance functions coordinate and monitor conformity with applicable requirements, and audit functions independently assess controls and report findings.

IT Audit

IT audit is the systematic examination of IT systems, services, processes, and controls to determine whether they operate as intended, support organizational objectives, manage relevant risks, and conform to established audit criteria.

IT audits assess the design and implementation of IT controls, examine supporting evidence, identify deficiencies, and communicate findings to the appropriate stakeholders. The scope of an audit depends on the objectives of the assessment, the IT environment being examined, the associated risks, and the applicable requirements.

Objectives of IT Audit

The objectives of IT audit include:

• Evaluating the design and operating effectiveness of IT controls.
• Assessing whether IT systems and services operate in accordance with approved policies and procedures.
• Identifying weaknesses in IT governance, processes, and control implementation.
• Evaluating the protection of information and technology resources.
• Assessing the management of IT risks and control deficiencies.
• Verifying whether applicable requirements are addressed through appropriate IT controls.
• Providing management with independent findings and recommendations for improvement.

Scope of IT Audit

The scope of an IT audit defines the systems, processes, locations, controls, and activities included in the assessment.

Depending on the audit objectives, the scope may include IT governance, infrastructure, applications, networks, identity and access management, data management, IT operations, change management, service management, backup and recovery, and business continuity arrangements.

An IT audit may examine an entire IT environment or focus on a specific system, service, process, control, or business function. Defining the scope helps establish clear assessment boundaries and ensures that the audit addresses its intended objectives.

Types of IT Audit

IT audits can be classified according to their objectives and the areas being assessed.

IT Governance Audit

Examines IT governance arrangements, decision-making structures, policies, responsibilities, and oversight mechanisms to determine whether IT activities align with organizational objectives and established governance requirements.

IT Infrastructure Audit

Assesses the configuration, management, security, availability, and operational controls associated with servers, endpoints, networks, virtualization platforms, storage systems, and data center environments.

IT Application Audit

Examines application controls, access permissions, transaction processing, configuration, change management, and other controls relevant to the reliability and security of applications.

IT Operations Audit

Evaluates IT operational processes, including system administration, incident management, problem management, configuration management, backup operations, monitoring, and service delivery.

IT Security Audit

Assesses security policies, technical safeguards, access controls, security monitoring, vulnerability management, and other controls intended to protect IT systems and information.

IT Compliance Audit

Evaluates whether relevant IT systems, processes, and controls conform to applicable legal, regulatory, contractual, industry, and organizational requirements.

IT Business Continuity and Disaster Recovery Audit

Examines backup arrangements, recovery procedures, continuity plans, recovery capabilities, and testing practices to assess whether the IT environment can support the restoration of systems and services following disruption.

These audit types may overlap. An audit can cover multiple areas when they contribute to the same assessment objectives.

IT Audit Areas

IT audits may examine the following areas:

• IT Governance: Governance structures, policies, decision-making, responsibilities, and oversight.
• IT Infrastructure: Servers, endpoints, networks, storage, virtualization, and data center environments.
• Applications and Information Systems: Application controls, system configuration, processing, and system reliability.
• Identity and Access Management: User provisioning, authentication, authorization, privileged access, and access reviews.
• IT Change Management: Change authorization, testing, approval, implementation, and rollback procedures.
• IT Operations and Service Management: Operational procedures, incident handling, problem management, service availability, and configuration management.
• Data Management: Data handling, retention, access restrictions, backup, recovery, and integrity controls.
• IT Security: Security policies, technical safeguards, vulnerability management, monitoring, and incident response.
• Business Continuity and Disaster Recovery: Continuity arrangements, recovery plans, backup systems, and recovery testing.
• Third-Party IT Services: Oversight of service providers, contractual obligations, service performance, and relevant controls.

The audit scope determines which areas are examined and the depth of assessment applied to each.

IT Audit Criteria and Evidence

IT audit criteria establish the requirements against which an IT environment is assessed. These criteria may be derived from organizational policies, approved procedures, contractual obligations, applicable laws and regulations, industry standards, and recognized frameworks.

Audit evidence consists of information collected to support assessment findings and conclusions. Depending on the audit objectives, evidence may include system configurations, access records, change tickets, policies, procedures, logs, reports, configuration baselines, interview responses, and test results.

Auditors evaluate whether the evidence is relevant and sufficient to support their conclusions. Documented evidence helps establish the basis for findings, supports traceability, and enables appropriate follow-up.

IT Compliance

IT compliance focuses on ensuring that IT systems, services, processes, and controls conform to applicable requirements. These requirements may arise from laws, regulations, contracts, industry standards, organizational policies, and internal procedures.

IT compliance involves identifying applicable requirements, determining how they affect the IT environment, mapping them to relevant controls, assessing conformity, monitoring compliance status, and addressing identified gaps.

Compliance responsibilities are shared across the organization. IT teams implement and maintain the necessary controls, compliance functions coordinate and monitor compliance activities, and management oversees the resolution of significant gaps.

Objectives of IT Compliance

The objectives of IT compliance include:

• Identifying requirements applicable to IT systems and services.
• Translating applicable requirements into operational controls and procedures.
• Supporting consistent implementation of IT policies and control requirements.
• Monitoring conformity with established requirements.
• Maintaining documentation and evidence of compliance activities.
• Identifying and addressing compliance gaps.
• Supporting regulatory, contractual, and internal reporting obligations.

IT Compliance Requirements

IT compliance requirements may originate from several sources.

Legal and Regulatory Requirements

Laws and regulations may impose obligations concerning information protection, privacy, records management, electronic transactions, operational resilience, and other aspects of technology use. The applicable requirements depend on the organization’s jurisdiction, industry, activities, and the information it processes.

Contractual Requirements

Contracts with customers, suppliers, business partners, and service providers may establish requirements for data protection, service availability, access management, incident notification, record retention, and assurance reporting.

Industry Standards and Frameworks

Organizations may adopt standards and frameworks to establish consistent control practices, demonstrate conformity with specified requirements, or support independent assessments.

Organizational Policies and Procedures

Internal policies, standards, and procedures establish the organization’s own requirements for the management, use, security, and operation of IT resources.

Organizations need to identify which requirements apply to their specific environment rather than assuming that every law, regulation, or standard applies universally.

IT Compliance Areas

IT compliance may address the following areas:

• Information Security: Implementation of controls that protect information and IT resources.
• Data Protection and Privacy: Appropriate handling, access, retention, and disposal of personal and other protected information.
• Identity and Access Management: Management of user identities, permissions, privileged access, and access reviews.
• IT Operations: Adherence to approved operational procedures, service management requirements, and configuration standards.
• Change Management: Compliance with established change approval, testing, implementation, and documentation procedures.
• Data Retention and Records Management: Compliance with applicable requirements for retaining, retrieving, protecting, and disposing of records.
• Service Availability and Resilience: Implementation of relevant continuity, recovery, and availability requirements.
• Third-Party IT Services: Compliance with applicable contractual and organizational requirements governing external service providers.

The applicable compliance areas depend on the organization’s obligations, technology environment, business activities, and risk exposure.

IT Compliance Assessment

IT compliance assessment determines whether relevant IT processes, systems, and controls conform to applicable requirements.

The assessment typically involves identifying the requirements, mapping them to controls, gathering supporting evidence, evaluating implementation, recording gaps, and determining the actions required to address deficiencies.

Assessment methods may include document reviews, interviews, configuration reviews, control testing, evidence examination, and validation of operational procedures.

The results provide visibility into compliance status and help management prioritize corrective actions according to the significance of the gaps and the applicable obligations.

IT Compliance Monitoring and Reporting

IT compliance monitoring involves periodically reviewing controls, processes, and evidence to determine whether applicable requirements continue to be met.

Monitoring activities may include reviewing control records, tracking changes to requirements, examining exceptions, validating corrective actions, and assessing whether changes to systems or services affect compliance obligations.

Compliance reporting communicates the status of compliance activities, identified gaps, unresolved issues, and remediation progress to relevant stakeholders. Reporting frequency and content depend on organizational governance arrangements, applicable requirements, and the significance of the issues identified.

IT Governance, Risk, and Controls

IT Audit and Compliance operates within the broader IT governance and risk management environment. Governance establishes direction, responsibilities, and oversight; risk management identifies and evaluates uncertainties that may affect IT objectives; and controls help manage identified risks and meet applicable requirements.

Audit and compliance activities provide information about how effectively these arrangements operate and where improvements may be required.

IT Governance and Accountability

IT governance establishes how decisions concerning IT resources, services, investments, risks, and controls are directed and overseen.

Governance arrangements define responsibilities, approval authorities, reporting relationships, and mechanisms for monitoring IT performance and control effectiveness. They also establish how IT-related issues are escalated and how management decisions are documented.

Audit and compliance activities can assess whether these arrangements are appropriately established and followed.

IT Risk and Control Assessment

IT risk and control assessment examines the risks associated with IT systems, services, processes, and technology dependencies, along with the controls intended to manage those risks.

Assessments may consider unauthorized access, service disruption, data loss, configuration weaknesses, inadequate change control, operational failures, and third-party dependencies.

The results help identify control deficiencies and support decisions about remediation priorities. Detailed risk identification, analysis, evaluation, and treatment practices belong to the broader Risk Management domain.

IT Policies, Standards, and Procedures

IT policies establish management expectations and mandatory requirements for the use, security, and operation of technology resources. Standards define specific requirements, while procedures describe how activities are performed.

Audit and compliance assessments examine whether these documents are approved, communicated, maintained, and followed in practice. They may also evaluate whether documented requirements are supported by appropriate controls and evidence.

IT Internal Controls

IT internal controls are the policies, processes, procedures, and technical mechanisms used to support the reliable operation, security, and governance of IT resources.

Examples include access restrictions, segregation of duties, change approvals, configuration management, backup controls, activity logging, monitoring, and incident handling procedures.

Control owners are responsible for implementing and operating assigned controls. Audit and compliance activities evaluate relevant controls to determine whether they are appropriately designed, implemented, and operating as intended.

Control Effectiveness and Assurance

Control effectiveness concerns whether controls are appropriately designed and consistently operate to achieve their intended objectives.

Assessments may identify controls that are missing, incorrectly configured, inconsistently performed, inadequately documented, or ineffective in practice.

The resulting findings help management understand control weaknesses, determine appropriate corrective actions, and assess whether additional assurance or testing is required.

IT Audit and Compliance Responsibilities

Effective IT Audit and Compliance depends on clearly defined responsibilities and appropriate coordination among IT management, control owners, compliance functions, internal audit, external auditors, and other relevant stakeholders.

Although responsibilities vary by organizational structure, the distinction between operating controls, monitoring compliance, and independently auditing controls should remain clear.

IT Management and Control Owners

IT management and control owners are responsible for implementing and operating the IT processes and controls assigned to them.

Their responsibilities may include maintaining policies and procedures, managing system configurations, retaining operational records, providing audit evidence, addressing control deficiencies, and implementing approved corrective actions.

They are also responsible for ensuring that identified issues are escalated and resolved within their assigned authority.

IT Compliance Functions

Compliance functions help identify applicable requirements, coordinate compliance assessments, maintain compliance records, monitor identified gaps, and report compliance status.

They may work with legal, risk management, information security, and IT teams to interpret requirements and determine how those requirements should be addressed within the IT environment.

Their responsibilities depend on the organization’s governance model and do not automatically include ownership of every IT control.

Internal Audit

Internal audit provides independent and objective assurance concerning governance, risk management, and control processes.

In the IT environment, internal audit may assess IT governance, access controls, infrastructure, applications, IT operations, security controls, and compliance with applicable criteria.

Internal auditors evaluate evidence, document findings, communicate conclusions, and follow up on agreed corrective actions. To preserve audit independence, internal audit should not assume management responsibility for designing, implementing, or operating the controls it independently evaluates.

External Auditors

External auditors perform independent assessments according to the engagement objectives, applicable professional requirements, and agreed audit criteria.

Their work may include examining IT controls that affect financial reporting, evaluating specified compliance requirements, or assessing controls within a defined assurance engagement.

The scope of external audit depends on the engagement. An external financial statement audit, for example, is not automatically a comprehensive assessment of the organization’s entire IT security environment.

Roles in Remediation and Follow-Up

Management and designated control owners are responsible for addressing findings and implementing corrective actions. Compliance functions may coordinate the tracking of compliance gaps, while audit functions independently evaluate findings and perform follow-up activities within their mandate.

Remediation should identify the issue, determine its underlying cause, assign an accountable owner, establish a target date, and define the evidence required to demonstrate completion.

Where appropriate, significant or overdue issues should be escalated to management or the relevant governance body.

IT Audit and Compliance Coordination

IT audit and compliance activities frequently examine overlapping systems, processes, and controls. Effective coordination helps reduce unnecessary duplication, improve evidence management, and ensure that identified deficiencies are addressed consistently.

Coordination must not compromise the independence of audit functions or blur management’s responsibility for operating controls.

Audit Findings and Compliance Gaps

Audit findings describe deficiencies or other matters identified during an audit in relation to the applicable criteria. Compliance gaps identify instances where an applicable requirement has not been met or where sufficient evidence of conformity is unavailable.

A single issue may result in both an audit finding and a compliance gap. However, the terms are not interchangeable: an audit finding may concern control effectiveness or governance even when no specific compliance breach has been established.

Organizations should document identified issues clearly, including the relevant criteria, supporting evidence, potential impact, and required action.

Corrective and Remediation Actions

Corrective actions address identified deficiencies and seek to prevent their recurrence. Remediation may involve correcting a technical configuration, updating a procedure, strengthening a control, improving documentation, or addressing an underlying process weakness.

Each action should have an assigned owner, an agreed target date, and defined completion criteria. The extent and urgency of remediation should reflect the significance of the issue, applicable obligations, and the potential consequences of leaving it unresolved.

Evidence and Documentation Management

Evidence and documentation support the assessment of IT controls and the demonstration of compliance with applicable requirements.

Relevant records may include approved policies, procedures, system configurations, access reviews, change approvals, incident records, monitoring reports, backup logs, and remediation evidence.

Organizations should maintain evidence in a manner that supports accuracy, traceability, appropriate access, retention, and retrieval. Evidence should be sufficient to demonstrate the control activity or requirement being assessed.

Compliance Reporting and Audit Follow-Up

Compliance reporting communicates the status of applicable requirements, assessment results, identified gaps, and remediation progress. Audit reporting communicates the scope of the audit, findings, conclusions, and relevant recommendations.

Follow-up activities determine whether agreed actions have been completed and whether the identified deficiencies have been adequately addressed. Depending on the issue, this may require reviewing documentation, examining updated configurations, testing controls, or obtaining additional evidence.

Significant unresolved issues should be escalated through the appropriate management and governance channels.

Continuous Improvement of IT Controls

IT Audit and Compliance can contribute to the continuous improvement of IT controls by identifying recurring weaknesses, ineffective procedures, gaps in documentation, and opportunities to strengthen control design.

Organizations can use assessment results, incident trends, compliance monitoring, and remediation outcomes to improve IT processes and control implementation.

Improvements should be evaluated to determine whether they address the underlying issue and remain effective as IT systems, services, risks, and requirements change.

IT Audit and Compliance Frameworks and Standards

Frameworks and standards provide structured guidance and criteria that organizations can use to establish, assess, and improve IT governance, controls, information security, and service management.

Their relevance depends on the organization’s objectives, applicable requirements, and the scope of the audit or compliance assessment.

COBIT

COBIT provides a framework for the governance and management of enterprise information and technology. It can support the definition of governance objectives, management practices, control expectations, and performance assessment criteria.

In IT Audit and Compliance, COBIT may be used to structure assessments of IT governance and management practices, evaluate control arrangements, and identify areas for improvement.

ISO/IEC 27001

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system.

It can provide criteria for assessing an organization’s information security management arrangements and its treatment of information security risks. The scope of an assessment depends on the defined management system and the applicable audit criteria.

ISO/IEC 20000-1

ISO/IEC 20000-1 specifies requirements for a service management system. It is relevant to assessments of service management processes, service delivery, and the management of IT services within the defined scope.

Organizations may use it to evaluate whether their service management system conforms to the applicable requirements.

NIST Frameworks and Standards

NIST publishes frameworks, standards, and guidance addressing cybersecurity, information security, risk management, and related technical controls.

Depending on the assessment objectives, relevant NIST publications can provide reference criteria for evaluating cybersecurity practices, risk management arrangements, and security controls. The appropriate publication should be selected according to the environment and assessment requirements.

Regulatory, Contractual, and Organizational Requirements

In addition to frameworks and standards, IT audits and compliance assessments may use applicable legal and regulatory requirements, contractual obligations, and internal policies as assessment criteria.

Organizations should determine which requirements apply to their operations and identify the controls and evidence needed to demonstrate conformity.

Adopting a framework or standard does not, by itself, establish compliance with every applicable law, regulation, or contractual obligation. Applicability and conformity must be evaluated against the relevant requirements.

IT Controls

Understanding IT Controls

IT controls are safeguards, measures, and mechanisms established to protect an organization’s IT assets, infrastructure, systems, applications, services, and information against security threats, operational failures, unauthorized activities, and other risks. Within IT Security, controls translate security policies, standards, risk treatment requirements, and business objectives into practical measures that protect the enterprise and its technology environment. These controls are implemented through administrative processes, technical mechanisms, and physical safeguards. In practice, control requirements are realized through security platforms, technologies, tools, and solutions that enforce policies, restrict access, monitor activities, detect threats, prevent unauthorized actions, and support incident response and recovery. Examples include identity and access management platforms, firewalls, endpoint security solutions, security information and event management systems, encryption technologies, backup solutions, and physical access control systems. Together, these controls and their supporting technologies form the operational foundation of IT Security, helping protect enterprise resources, IT infrastructure, applications, data, and business services.

Primary Controls

Primary controls classify safeguards according to their nature and how they are implemented. They establish the administrative requirements, technical mechanisms, and physical protections needed to secure the enterprise and its IT environment.

Administrative Controls

Administrative controls are established through organizational policies, standards, procedures, responsibilities, and management processes. They define the rules and practices that personnel must follow when using, managing, and protecting IT resources.

These controls establish governance and operational requirements for managing access, approving changes, handling incidents, monitoring compliance, and addressing security risks.

Examples include:

• IT security policies and standards.
• User access approval and periodic access reviews.
• Change management procedures.
• Segregation of duties.
• Security awareness and training.
• IT risk assessments and risk treatment procedures.
• Supplier and third-party security requirements.
• Incident management procedures.
• Periodic compliance reviews.

Technical Controls

Technical controls use hardware, software, system configurations, and automated mechanisms to enforce security requirements and protect IT resources. They operate across endpoints, servers, networks, applications, databases, cloud environments, and other technology platforms.

These controls can enforce access restrictions, prevent unauthorized activities, detect suspicious behavior, and support response and recovery.

Examples include:

• Authentication and multi-factor authentication.
• Identity and access management solutions.
• Firewalls and network filtering.
• Encryption technologies.
• Endpoint security platforms.
• Intrusion detection and prevention systems.
• Security information and event management (SIEM) systems.
• Secure configuration enforcement.
• Application input validation.
• Automated backup and recovery mechanisms.

Physical Controls

Physical controls protect facilities, equipment, and physical access points against unauthorized access, damage, theft, and environmental threats. They help safeguard data centers, server rooms, network equipment, endpoints, and other IT assets.

Examples include:

• Physical access cards and biometric access systems.
• Security guards and visitor management.
• Locks on server rooms and equipment cabinets.
• CCTV surveillance.
• Physical barriers and secure perimeters.
• Fire detection and suppression systems.
• Environmental monitoring for temperature and humidity.
• Power protection and backup power systems.
• Secure disposal of storage media and equipment.

Functional Controls

Functional controls classify safeguards according to their intended purpose. They describe what controls are designed to achieve, rather than the form in which they are implemented.

A control may serve more than one function. For example, restricting administrative privileges can prevent unauthorized access, while monitoring privileged activities can help detect misuse.

Preventive Controls

Preventive controls are designed to stop or reduce the likelihood of unwanted events before they occur. They restrict unauthorized activities, enforce security requirements, and reduce opportunities for errors or security violations.

Examples include:

• Requiring multi-factor authentication for sensitive systems.
• Restricting administrative privileges according to job responsibilities.
• Requiring approval before production changes.
• Validating application input before processing.
• Enforcing secure system configurations.
• Separating the responsibilities for requesting, approving, and implementing sensitive changes.
• Restricting physical access to server rooms.

Detective Controls

Detective controls identify security incidents, unauthorized activities, errors, control failures, or policy violations that have occurred or are in progress. They provide information that enables personnel to investigate events and initiate appropriate responses.

Their effectiveness depends on timely identification, appropriate alerting, investigation, and escalation.

Examples include:

• Reviewing system and administrative activity logs.
• Monitoring failed authentication attempts.
• Detecting unusual network traffic.
• Reconciling application transactions.
• Reviewing configuration changes.
• Monitoring backup failures.
• Reviewing physical access records.
• Identifying unauthorized changes to critical systems.

Corrective Controls

Corrective controls address identified problems, weaknesses, or failures. They help restore systems, services, data, and processes to an acceptable state and reduce the likelihood of the same problem recurring.

Examples include:

• Correcting inaccurate or incomplete records.
• Reverting a failed production change.
• Removing unauthorized access privileges.
• Applying a fix to a security vulnerability.
• Correcting a misconfigured system.
• Addressing the root cause of a recurring operational failure.
• Restoring affected services following an incident.

Deterrent Controls

Deterrent controls are intended to discourage individuals from attempting unauthorized activities, violating security requirements, or misusing IT resources. They communicate that prohibited behavior may be detected and may result in consequences.

Deterrent controls do not guarantee that incidents will be prevented. Their purpose is to reduce the likelihood of unwanted behavior.

Examples include:

• Security warning banners on systems.
• Notices explaining acceptable use and monitoring.
• Disciplinary policies for security violations.
• Visible security surveillance.
• Clearly communicated consequences for unauthorized access.
• Formal acknowledgment of information security policies.

Directive Controls

Directive controls communicate the actions, behaviors, and procedures that personnel are required to follow. They provide instructions and establish expectations for handling IT resources, information, and security-related activities.

Examples include:

• IT security policies and standards.
• Secure configuration guidelines.
• Incident reporting procedures.
• Data classification and handling requirements.
• Instructions for handling sensitive information.
• Acceptable use policies.
• Procedures for granting and reviewing user access.
• Security awareness and role-specific training.

Compensating Controls

Compensating controls provide alternative safeguards when a preferred or primary control cannot be implemented, is unavailable, or does not adequately address a risk. They are intended to reduce the remaining risk to an acceptable level.

Their suitability should be evaluated against the original security requirement. Their use should be documented, justified, approved where required, and reviewed periodically.

Examples include:

• Additional monitoring when a system cannot support a required security feature.
• Restricting network access to a legacy system that cannot support stronger authentication.
• Increasing manual reviews when an automated control is unavailable.
• Applying additional access restrictions to an older application.
• Introducing independent approval and reconciliation when a system cannot enforce segregation of duties automatically.

Recovery Controls

Recovery controls help restore IT systems, services, applications, and information following a disruption, failure, or security incident. They support the resumption of business operations and restoration of required service levels.

Examples include:

• Restoring systems and data from backups.
• Recovering services in a disaster recovery environment.
• Activating documented disaster recovery procedures.
• Rebuilding compromised servers from trusted configurations.
• Restoring application services following a failure.
• Testing backup restoration and recovery procedures.
• Maintaining documented recovery responsibilities and procedures.

Objectives of IT Controls

IT controls support several objectives that contribute to the secure and reliable management of IT resources.

Protecting IT Assets and Information

IT controls protect hardware, software, applications, systems, and information against unauthorized access, misuse, alteration, loss, and damage. They support the confidentiality, integrity, and availability of information.

Ensuring Reliable IT Operations

IT controls help ensure that IT systems and services operate consistently, operational procedures are followed, and disruptions are identified and addressed.

Maintaining Data Integrity

IT controls help maintain the accuracy, completeness, consistency, and validity of data throughout its creation, processing, storage, and transfer.

Managing IT Risks

IT controls reduce the likelihood of undesirable events, limit their potential impact, and support the detection, response, and recovery activities needed to manage IT risks.

Supporting IT Governance and Accountability

IT controls translate policies, standards, and management decisions into operational requirements. They establish responsibilities, approval processes, and oversight mechanisms.

Meeting Compliance Requirements

IT controls support compliance with applicable laws, regulations, contractual obligations, industry requirements, and organizational policies. They also generate evidence for assessments and audits.

Supporting Business Continuity and Recovery

IT controls help maintain critical services and restore systems, applications, and information following failures, security incidents, or other disruptive events.

IT General Controls

IT General Controls (ITGCs) are controls that support the reliable management and operation of the IT environment underlying applications, systems, and business processes. They generally apply across multiple systems or services rather than to a specific business transaction.

ITGCs are particularly important where business processes depend on the integrity, availability, and security of the underlying IT environment. Their scope depends on the organization’s systems, risks, business requirements, and applicable assessment criteria.

Access Management

Access management controls ensure that users and other identities receive appropriate access to systems, applications, data, and infrastructure according to their responsibilities.

Key activities include:

• Approving account creation and access changes.
• Applying least-privilege principles.
• Authorizing and monitoring privileged access.
• Reviewing access periodically.
• Modifying or removing access when responsibilities change or users leave.
• Monitoring privileged activities.
• Managing service accounts and other non-human identities.

Change Management

Change management controls ensure that modifications to systems, applications, infrastructure, and configurations are assessed, authorized, tested, implemented, and documented appropriately.

Uncontrolled changes can introduce security weaknesses, disrupt services, or affect data integrity.

Key activities include:

• Recording and classifying changes.
• Assessing risks and potential impacts.
• Obtaining appropriate approval.
• Testing changes before production implementation.
• Restricting production change privileges.
• Documenting implementation and rollback procedures.
• Reviewing emergency changes after implementation.

IT Operations Management

IT operations management controls support the consistent operation, monitoring, and maintenance of IT systems and services. They help ensure that operational activities follow defined procedures and that failures are identified and addressed.

Key activities include:

• Monitoring system availability and performance.
• Managing scheduled jobs and operational tasks.
• Reviewing system logs and alerts.
• Recording and investigating incidents.
• Identifying recurring operational problems.
• Monitoring resource capacity.
• Maintaining operational procedures and records.

Backup and Recovery

Backup and recovery controls protect the recoverability of information, applications, and systems when data is lost, corrupted, deleted, or becomes inaccessible.

Creating backups alone is insufficient. Backup copies must be appropriately protected, monitored, retained, and tested to establish that they can be restored when needed.

Key activities include:

• Defining backup scope and schedules.
• Protecting backup copies against unauthorized access and alteration.
• Establishing retention requirements.
• Monitoring backup success and failure.
• Testing restoration procedures.
• Defining recovery requirements for critical services.
• Maintaining recovery documentation and responsibilities.

System Development and Maintenance

System development and maintenance controls help ensure that systems and applications are developed, tested, deployed, modified, and retired through controlled processes.

These controls reduce the risk of defects, unauthorized changes, security weaknesses, and operational failures.

Key activities include:

• Applying defined development and testing procedures.
• Separating development, testing, and production environments where appropriate.
• Reviewing code and testing security requirements.
• Controlling application releases and deployments.
• Managing third-party components and dependencies.
• Applying patches and security updates.
• Maintaining technical documentation.
• Decommissioning systems and removing associated access appropriately.

IT Application Controls

IT application controls are safeguards built into or applied directly to individual applications and business processes. They help ensure that transactions and other processing activities are authorized, complete, accurate, valid, and processed as intended.

Unlike IT General Controls, which support the broader IT environment, application controls focus on the processing and information-handling activities of a particular application or business process.

Application controls may be automated, manual, or a combination of both.

Input Controls

Input controls help ensure that data entered into an application is valid, complete, and appropriate for processing.

Examples include:

• Mandatory field validation.
• Format and range checks.
• Validation of transaction references.
• Duplicate-entry detection.
• Authorization checks before accepting a transaction.

Processing Controls

Processing controls help ensure that an application processes data and transactions correctly according to its defined logic and business rules.

Examples include:

• Calculation verification.
• Duplicate transaction detection.
• Processing sequence checks.
• Validation of transaction status.
• Automated checks for incomplete processing.

Output Controls

Output controls help ensure that application-generated reports, statements, files, and other outputs are accurate, complete, appropriately approved where required, and provided only to authorized recipients.

Examples include:

• Reconciling output totals.
• Reviewing sensitive reports.
• Restricting access to generated reports.
• Validating report completeness.
• Controlling the distribution of exported data.

Interface Controls

Interface controls help ensure that information transferred between applications, systems, or services is complete, accurate, and successfully processed.

Examples include:

• Comparing record counts between source and destination systems.
• Reconciling transaction totals.
• Monitoring failed data transfers.
• Reviewing interface error reports.
• Verifying that rejected records are investigated and resolved.

Data Validation and Integrity Controls

Data validation and integrity controls enforce rules that help maintain valid relationships, consistency, and correctness within application data.

Examples include:

• Referential integrity checks.
• Uniqueness constraints.
• Validation against approved reference data.
• Data type and format validation.
• Checks for inconsistent or invalid relationships between records.

Application controls often depend on the effectiveness of IT General Controls. For example, an application may enforce an approval rule, but unauthorized changes to its configuration could undermine that rule if access and change controls are ineffective.

IT Security Control Implementation and Management

IT security control implementation and management involve translating identified risks, security requirements, and policies into safeguards that are established, operated, monitored, and maintained.

Control selection should reflect the risk being addressed, the importance of the system, operational requirements, and applicable obligations.

Identifying Control Requirements

Control requirements may arise from risk assessments, organizational policies, contractual obligations, regulatory requirements, audit findings, security incidents, and business needs.

Requirements should identify the risk to be addressed and the intended security outcome.

Selecting Appropriate Controls

Control selection should consider the nature of the risk, its likelihood and impact, existing safeguards, implementation costs, and operational constraints.

Each selected control should address a defined requirement rather than being implemented solely because it is commonly used elsewhere.

Assigning Control Ownership

Each control should have a clearly identified owner responsible for ensuring that it is implemented, maintained, and reviewed appropriately.

Operational activities may be delegated, but accountability for oversight, performance, and remediation should remain clear.

Implementing Controls

Controls may be implemented through policies, workflows, technical configurations, automated mechanisms, operational procedures, and management practices.

Implementation may require system changes, approval processes, documentation, training, and coordination among different teams.

Maintaining Control Documentation

Control documentation should describe the control’s purpose, scope, ownership, operating procedure, frequency, expected evidence, and escalation requirements.

Documentation supports consistent operation, evaluation, auditability, and future maintenance.

Monitoring Control Operation

Control monitoring helps determine whether controls continue to operate as intended and remain suitable as systems, processes, and risks change.

Monitoring activities may include reviewing records, investigating exceptions, checking completion of required activities, and tracking control failures.

IT Control Design and Implementation

Control design and implementation are related but distinct activities. Design determines whether a control is suitable for its intended purpose, while implementation establishes the control in the actual IT environment.

Control Design

Control design defines how a safeguard should address a specific risk or requirement. It should identify the activity to be performed, the responsible party, the conditions under which the control operates, and the expected outcome.

Design considerations include the control objective, risk level, frequency, independence, evidence requirements, and exception-handling procedures.

Control Implementation

Control implementation puts the approved design into practice. It may involve configuring systems, assigning responsibilities, developing procedures, establishing workflows, and training personnel.

A well-designed control may still fail if it is implemented incorrectly or inconsistently.

Control Automation

Automation can improve the consistency, repeatability, and speed of control execution.

Examples include automated access provisioning, configuration enforcement, alert generation, and validation of application data. Automated controls still depend on appropriate configuration, access restrictions, maintenance, and monitoring.

Control Integration

Controls should be integrated into relevant IT management and operational processes, including access administration, change management, system maintenance, incident handling, and service operations.

Integrating controls into established workflows can improve consistency and reduce the likelihood that required activities will be overlooked.

Control Documentation

Control documentation should support operation, monitoring, testing, and future changes. It should be updated when control responsibilities, configurations, processes, or requirements change.

IT Control Testing and Evaluation

IT control testing and evaluation determine whether controls are appropriately designed, implemented, and operating effectively.

Testing may be performed by control owners, IT management, risk and compliance teams, or internal and external auditors, depending on the purpose of the assessment and the level of independence required.

Evaluating Control Design

Design evaluation determines whether a control, if performed as intended, can address the relevant risk or meet the stated requirement.

For example, an approval process should ensure that privileged access is authorized by an appropriate person before it is granted.

Verifying Control Implementation

Implementation verification determines whether the control has been established as designed.

Evidence may include system configurations, approved procedures, workflow settings, permissions, and implementation records.

Testing Operating Effectiveness

Operating effectiveness testing determines whether the control operated consistently and as intended over the period being assessed.

Testing methods may include examining samples of transactions, inspecting logs and records, observing activities, and independently repeating selected control procedures.

Reviewing Control Evidence

Control evidence should be relevant, reliable, and sufficient to support the assessment conclusion.

Examples include approval records, access reviews, change tickets, system logs, backup reports, reconciliations, and incident records.

Documenting Test Results

Test results should identify the control assessed, the testing approach, the evidence reviewed, exceptions identified, and the resulting conclusion.

Deficiencies should be communicated to the appropriate control owners and management personnel.

Defining Testing Frequency

Testing frequency should reflect risk, control importance, how often the control operates, changes in the environment, previous test results, and applicable requirements.

Higher-risk controls or controls affected by significant changes may require more frequent evaluation.

IT Control Effectiveness and Assurance

Control effectiveness refers to the extent to which a control achieves its intended objective and operates as required. The existence of a policy or documented procedure alone does not demonstrate that a control is effective.

Design Effectiveness

Design effectiveness determines whether the control is suitably designed to address the relevant risk or requirement.

A poorly designed control may fail even when personnel follow the documented procedure.

Implementation Effectiveness

Implementation effectiveness determines whether the control has been established correctly, with the required mechanisms, responsibilities, and procedures in place.

Operating Effectiveness

Operating effectiveness determines whether the control operates consistently and as intended.

Missed reviews, incomplete evidence, unauthorized exceptions, and inconsistent execution may indicate weaknesses.

Control Assurance

Control assurance provides confidence that controls are appropriately designed, implemented, and operating effectively.

Assurance may be obtained through management reviews, control self-assessments, compliance assessments, independent testing, and audits. The required level of assurance depends on the control’s importance, the associated risk, and applicable requirements.

Continuous Monitoring

Continuous or periodic monitoring helps identify control failures, emerging weaknesses, and changes that may affect effectiveness.

Monitoring results should inform control reassessment, corrective actions, and improvements to the wider control environment.

IT Control Deficiencies and Remediation

A control deficiency exists when a required control is absent, inadequately designed, improperly implemented, inconsistently performed, or unable to achieve its intended objective.

Deficiencies may be identified through monitoring, testing, incidents, risk assessments, compliance activities, or audits.

Identifying Control Deficiencies

Deficiencies should be documented with sufficient information to describe their nature, affected systems or processes, relevant control objectives, and supporting evidence.

Assessing Severity and Impact

Assessment should consider the likelihood and potential impact of the deficiency, system importance, data sensitivity, business dependencies, and any compensating controls.

Significant deficiencies should be escalated through the appropriate management and risk governance processes.

Root Cause Analysis

Root cause analysis determines why a deficiency occurred rather than addressing only its immediate symptoms.

Potential causes include poor control design, unclear responsibilities, inadequate resources, technical limitations, configuration errors, insufficient procedures, and failure to follow established requirements.

Developing Remediation Plans

Remediation plans should identify the corrective actions required, accountable owners, target dates, necessary resources, and methods for validating completion.

Actions should be prioritized according to the risk and potential impact of the deficiency.

Implementing Corrective Actions

Corrective actions may involve redesigning controls, correcting configurations, improving monitoring, updating procedures, restricting access, revising documentation, or providing additional training.

Where immediate remediation is not possible, interim safeguards and formal risk acceptance may be required through the organization’s authorized risk management process.

Tracking and Escalating Remediation

Remediation activities should be tracked to ensure that actions are completed within agreed timelines and address the identified deficiency.

Overdue, ineffective, or repeatedly deferred actions should be escalated to the appropriate management level.

Risk acceptance does not demonstrate that a deficiency has been corrected; it records an authorized decision to accept the remaining risk.

Validating Remediation

Remediation should be validated to confirm that the corrective actions address the underlying deficiency and that the control operates effectively.

A remediation item should be closed based on supporting evidence rather than simply because the planned activity has been completed.

IT Security Architecture

Objectives of IT Security Architecture

Security Alignment

Explanation of how security architecture aligns with business objectives, IT strategy, and enterprise architecture.

Risk Reduction

Explanation of how architectural decisions address security risks.

Security Integration

Explanation of how security capabilities are integrated across IT systems and services.

Consistent Security Design

Explanation of common security principles, standards, and architectural patterns.

Defense in Depth

Explanation of layered security controls.

Data Protection

Explanation of how confidentiality, integrity, and availability requirements influence architecture.

Regulatory and Policy Alignment

Explanation of how policies, standards, and regulatory obligations translate into security requirements.

Interoperability

Explanation of how security components integrate across IT environments.

Scalability and Flexibility

Explanation of how architecture accommodates changing requirements.

Lifecycle Security

Explanation of how security is incorporated throughout the IT lifecycle.

Scope of IT Security Architecture

Security Requirements and Principles

Identity and Access Architecture

Data Security Architecture

Network and Communication Security Architecture

Application and Software Security Architecture

Infrastructure and Platform Security Architecture

Cloud and Distributed Environment Security Architecture

Security Monitoring and Incident Response Architecture

Principles of IT Security Architecture

Security by Design

Defense in Depth

Least Privilege

Separation of Duties

Zero Trust

Secure Defaults

Segmentation and Isolation

Centralized Policy and Consistent Enforcement

Resilience and Recoverability

Risk-Based Design

IT Security Architecture Components

Security Architecture Principles

Security Requirements

Security Controls

Security Services

Security Components and Technologies

Trust Boundaries

Interfaces and Integration Points

Security Architecture Documentation

IT Security Architecture Models

Conceptual Security Architecture

Logical Security Architecture

Physical Security Architecture

Enterprise Security Architecture

Solution Security Architecture

IT Security Architecture Domains and Technologies

Identity and Access Security Architecture

Purpose and Scope

Explain the identity and access requirements covered by this domain.

Security Requirements

Explain the authentication, authorization, identity governance, and privileged access requirements.

Security Technologies and Platforms

• Identity and Access Management (IAM)
• Multi-Factor Authentication (MFA)
• Single Sign-On (SSO)
• Identity Governance and Administration (IGA)
• Privileged Access Management (PAM)
• Identity Providers (IdPs)
• Directory Services
• Secrets Management
• Identity Threat Detection and Response (ITDR)

Architectural Considerations

Explain identity integration, centralized access policies, lifecycle management, trust relationships, and access enforcement.

Network and Communication Security Architecture

Purpose and Scope

Explain the protection of network connectivity, communication pathways, and trust boundaries.

Security Requirements

Explain network access control, segmentation, traffic inspection, secure connectivity, and threat detection requirements.

Security Technologies and Platforms

• Network Firewalls
• Next-Generation Firewalls (NGFWs)
• Web Application Firewalls (WAFs)
• Proxy Servers
• Secure Web Gateways (SWGs)
• Intrusion Detection Systems (IDS)
• Intrusion Prevention Systems (IPS)
• Network Access Control (NAC)
• Virtual Private Networks (VPNs)
• Secure Access Service Edge (SASE)
• Security Service Edge (SSE)
• Zero Trust Network Access (ZTNA)
• DDoS Protection
• DNS Security
• Network Detection and Response (NDR)

Architectural Considerations

Explain network zoning, trust boundaries, traffic flows, inspection points, connectivity, and integration with identity and monitoring services.

Data Security Architecture

Purpose and Scope

Explain the protection of information throughout its lifecycle.

Security Requirements

Explain data classification, access control, encryption, integrity, retention, and secure disposal requirements.

Security Technologies and Platforms

• Data Loss Prevention (DLP)
• Data Security Posture Management (DSPM)
• Data Encryption
• Key Management Systems (KMS)
• Hardware Security Modules (HSMs)
• Tokenization
• Data Masking
• Database Activity Monitoring (DAM)
• Data Access Governance
• Cloud Access Security Brokers (CASBs)
• File Integrity Monitoring (FIM)
• Digital Rights Management (DRM)
• Secure File Transfer Platforms

Architectural Considerations

Explain data flows, storage locations, access permissions, encryption boundaries, key management, and information-sharing requirements.

Application and Software Security Architecture

Purpose and Scope

Explain the security requirements for applications, APIs, software components, and service integrations.

Security Requirements

Explain secure design, application access, input validation, software dependencies, API protection, and runtime security.

Security Technologies and Platforms

• Web Application Firewalls (WAFs)
• API Security Platforms
• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
• Software Composition Analysis (SCA)
• Interactive Application Security Testing (IAST)
• Runtime Application Self-Protection (RASP)
• Software Supply Chain Security
• Secrets Scanning
• Container Security
• Infrastructure as Code (IaC) Security
• Application Security Posture Management (ASPM)
• Web Application and API Protection (WAAP)

Architectural Considerations

Explain application trust boundaries, secure interfaces, authentication integration, service dependencies, and security across development and runtime environments.

Endpoint Security Architecture

Purpose and Scope

Explain the protection of user devices and other endpoint systems.

Security Requirements

Explain endpoint prevention, detection, response, device management, configuration, and data protection.

Security Technologies and Platforms

• Endpoint Protection Platforms (EPPs)
• Endpoint Detection and Response (EDR)
• Extended Detection and Response (XDR)
• Host-Based Intrusion Detection and Prevention Systems (HIDS/HIPS)
• Mobile Device Management (MDM)
• Unified Endpoint Management (UEM)
• Endpoint Privilege Management (EPM)
• Application Control and Allowlisting
• Endpoint Data Loss Prevention
• Device Control
• Endpoint Vulnerability Management

Architectural Considerations

Explain endpoint management, device trust, access to corporate resources, endpoint telemetry, and integration with identity and incident response services.

Server and Infrastructure Security Architecture

Purpose and Scope

Explain the security requirements for servers, operating environments, virtualization platforms, and supporting infrastructure.

Security Requirements

Explain secure configurations, administrative access, vulnerability management, workload protection, and infrastructure monitoring.

Security Technologies and Platforms

• Server Endpoint Protection
• Endpoint Detection and Response (EDR)
• Security Configuration and Compliance Tools
• Server Hardening Tools
• Vulnerability Management Platforms
• Patch Management Platforms
• File Integrity Monitoring (FIM)
• Privileged Access Management (PAM)
• Workload Protection Platforms
• Virtualization Security Platforms
• Infrastructure Monitoring and Logging Platforms

Architectural Considerations

Explain infrastructure dependencies, administrative trust boundaries, workload isolation, secure management interfaces, and integration with enterprise security services.

Detailed infrastructure implementation, hardening, and operational management should be covered under the separate Infrastructure Security domain where appropriate.

Cloud Security Architecture

Purpose and Scope

Explain security across cloud services, workloads, identities, data, and connectivity.

Security Requirements

Explain cloud access, configuration, workload protection, data security, logging, and compliance requirements.

Security Technologies and Platforms

• Cloud Security Posture Management (CSPM)
• Cloud Workload Protection Platforms (CWPPs)
• Cloud-Native Application Protection Platforms (CNAPPs)
• Cloud Infrastructure Entitlement Management (CIEM)
• Cloud Access Security Brokers (CASBs)
• Cloud Data Security Platforms
• Cloud Identity and Access Management
• Cloud Network Security Controls
• Cloud Web Application and API Protection
• Cloud Security Logging and Monitoring
• Cloud Key Management Services

Architectural Considerations

Explain cloud responsibility boundaries, identity federation, workload connectivity, data location, configuration governance, and integration across cloud and on-premises environments.

Email and Collaboration Security Architecture

Purpose and Scope

Explain the protection of email, messaging, file sharing, and collaboration services.

Security Requirements

Explain protection against phishing, malicious attachments, account compromise, unauthorized sharing, and data leakage.

Security Technologies and Platforms

• Secure Email Gateways
• SPF, DKIM, and DMARC
• Anti-Phishing Platforms
• Email Sandbox Platforms
• Cloud Email Security Platforms
• Collaboration Security Platforms
• Collaboration Data Loss Prevention
• Account Compromise Detection
• Email Encryption Solutions
• Domain Impersonation Protection

Architectural Considerations

Explain identity integration, email authentication, information-sharing policies, external communication, and security monitoring.

Security Monitoring and Incident Response Architecture

Purpose and Scope

Explain how security events are collected, analyzed, investigated, and acted upon.

Security Requirements

Explain logging coverage, event correlation, alerting, incident investigation, response coordination, and evidence preservation.

Security Technologies and Platforms

• Security Information and Event Management (SIEM)
• Security Orchestration, Automation, and Response (SOAR)
• Extended Detection and Response (XDR)
• Network Detection and Response (NDR)
• Endpoint Detection and Response (EDR)
• Threat Intelligence Platforms
• User and Entity Behavior Analytics (UEBA)
• Security Analytics Platforms
• Digital Forensics and Incident Response (DFIR) Tools
• Incident and Case Management Platforms
• Threat Hunting Tools

Architectural Considerations

Explain log sources, data retention, event correlation, monitoring coverage, response workflows, and integration with IT systems.

Vulnerability and Exposure Management Architecture

Purpose and Scope

Explain how vulnerabilities and security exposures are identified, prioritized, and tracked across the IT environment.

Security Requirements

Explain asset visibility, vulnerability discovery, risk prioritization, remediation tracking, and validation.

Security Technologies and Platforms

• Vulnerability Scanners
• Continuous Threat Exposure Management (CTEM) Platforms
• Attack Surface Management (ASM)
• External Attack Surface Management (EASM)
• Cyber Asset Attack Surface Management (CAASM)
• Cloud Security Posture Management (CSPM)
• Application Security Testing Tools
• Penetration Testing Tools
• Configuration Compliance Assessment Tools
• Risk-Based Vulnerability Management Platforms
• Patch Management Platforms

Architectural Considerations

Explain asset inventory integration, exposure visibility, business criticality, risk-based prioritization, remediation ownership, and validation.

Business Continuity and Recovery Security Architecture

Purpose and Scope

Explain how critical IT services, systems, and information can remain available or be restored following disruption.

Security Requirements

Explain backup protection, recovery objectives, resilience, recovery testing, and protection against attacks on recovery capabilities.

Security Technologies and Platforms

• Backup and Recovery Platforms
• Immutable Backup Technologies
• Data Replication Solutions
• Disaster Recovery Platforms
• High Availability Solutions
• Cyber Recovery Platforms
• Backup Security Monitoring
• Recovery Orchestration Tools
• Business Continuity Management Platforms

Architectural Considerations

Explain recovery dependencies, backup isolation, recovery access controls, resilience requirements, and integration with incident response.

Cryptographic Security Architecture

Purpose and Scope

Explain the use and management of cryptographic mechanisms to protect information, communications, identities, and system integrity.

Security Requirements

Explain encryption, key protection, certificate management, cryptographic standards, and secure key lifecycle operations.

Security Technologies and Platforms

• Public Key Infrastructure (PKI)
• Certificate Lifecycle Management Platforms
• Hardware Security Modules (HSMs)
• Key Management Systems (KMS)
• Enterprise Encryption Platforms
• Transport Layer Security (TLS)
• Code Signing Solutions
• Secrets Management Platforms
• Certificate Discovery and Monitoring Tools
• Cryptographic Policy and Compliance Tools

Architectural Considerations

Explain key ownership, certificate trust, cryptographic dependencies, key rotation, certificate renewal, and approved cryptographic standards.

Security Architecture for Third-Party and External Services

Purpose and Scope

Explain the security requirements for IT services, applications, integrations, and data exchanges involving external providers and business partners.

Security Requirements

Explain third-party access, external connectivity, information sharing, supplier risk, and security assurance.

Security Technologies and Platforms

• Third-Party Risk Management (TPRM) Platforms
• Software Supply Chain Security Platforms
• API Security Platforms
• Federated Identity Platforms
• Secure File Transfer Platforms
• Data Loss Prevention (DLP)
• Cloud Access Security Brokers (CASBs)
• External Attack Surface Management (EASM)
• Vendor Security Monitoring Services
• Security Rating and Assessment Platforms

Architectural Considerations

Explain external trust relationships, supplier access restrictions, data-sharing boundaries, integration security, and ongoing third-party risk oversight.

IT Security Architecture Development Lifecycle

Understanding Business and IT Requirements

Identify business objectives, IT services, applications, information assets, stakeholders, and operational requirements.

Assessing the Existing Environment

Review the existing architecture, system dependencies, data flows, security capabilities, and architectural constraints.

Identifying Security Requirements

Translate business needs, risk assessments, policies, standards, and regulatory obligations into security requirements.

Identifying Threats and Assessing Risks

Evaluate relevant threats, vulnerabilities, attack paths, trust relationships, and potential business impacts.

Developing the Security Architecture

Define the architecture, security components, control placements, trust boundaries, and integration points.

Evaluating Architectural Options

Compare design alternatives against security requirements, risk reduction, interoperability, scalability, operational needs, and cost.

Documenting Architecture Decisions

Record design decisions, alternatives, assumptions, dependencies, and accepted exceptions.

Reviewing and Approving the Architecture

Conduct the required architecture and security reviews and obtain approval from the appropriate stakeholders.

Implementing and Validating the Architecture

Implement the approved design and verify that the resulting solution meets its architectural and security requirements.

Monitoring and Maintaining the Architecture

Review and update the architecture as systems, threats, business needs, and security requirements change.

IT Security Architecture Governance

Architecture Principles and Standards

Establish approved principles, design standards, reusable patterns, and security requirements.

Architecture Review and Approval

Define review processes, approval responsibilities, and criteria for architectural decisions.

Security Architecture Roles and Responsibilities

Define the responsibilities of security architects, enterprise architects, solution architects, engineering teams, system owners, and risk owners.

Architecture Compliance

Evaluate solutions against approved principles, standards, requirements, and policies.

Risk Acceptance and Exceptions

Document deviations, assess associated risks, identify compensating measures, and follow established risk-acceptance processes.

Architecture Maintenance

Maintain architecture documentation, standards, design decisions, and reusable patterns.

IT Security Architecture Artifacts

Security Architecture Principles

Document the rules guiding security-related architectural decisions.

Security Requirements Document

Record the security requirements that systems and services must satisfy.

Security Architecture Diagrams

Represent architecture components, relationships, control placements, and trust boundaries.

Data Flow Diagrams

Illustrate information flows between systems, applications, services, and external entities.

Trust Boundary Diagrams

Identify boundaries between components and environments with different trust assumptions.

Security Architecture Decision Records

Record significant architectural decisions, alternatives, and their rationale.

Security Control Mapping

Map identified risks and requirements to relevant security controls.

Security Architecture Review Reports

Record review findings, recommendations, deviations, and approval decisions.

Architecture Standards and Patterns

Provide reusable design approaches for recurring security requirements.

Security Exception Records

Document approved deviations, associated risks, compensating controls, and review conditions.

IT Security Architecture Frameworks and Reference Models

Sherwood Applied Business Security Architecture (SABSA)

SABSA is a business-driven security architecture methodology that links business requirements and risk considerations to security services and architectural decisions.

The Open Group Architecture Framework (TOGAF)

TOGAF provides an enterprise architecture approach that can incorporate security considerations into architecture development and governance.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework provides an outcome-oriented structure for managing cybersecurity risk. Its outcomes can inform security requirements and architecture priorities.

NIST Security and Privacy Engineering Guidance

NIST security and privacy engineering publications provide guidance for integrating security requirements, risk considerations, and engineering principles into systems and their lifecycles.

ISO/IEC 27001 and ISO/IEC 27002

ISO/IEC 27001 specifies requirements for an information security management system, while ISO/IEC 27002 provides guidance on information security controls. Both can inform security architecture requirements and control selection.

COBIT

COBIT provides a framework for the governance and management of enterprise information and technology. It can inform the governance, oversight, and accountability arrangements surrounding IT Security Architecture.

IT Security and IT Service Management (ITSM)

Understanding ITSM

IT Service Management (ITSM) refers to the set of practices, processes, and activities an organization uses to design, deliver, operate, support, and improve IT services. It ensures that IT services meet business requirements, provide value to users, and operate within agreed service levels.

ITSM covers the management of IT services throughout their lifecycle, from identifying business needs and designing services to implementing, supporting, maintaining, and improving them. Frameworks and standards such as ITIL 4 and ISO/IEC 20000 provide guidance for establishing effective service management practices.

IT Security and ITSM

IT security protects IT systems, infrastructure, applications, services, and information against unauthorized access, misuse, disruption, modification, and destruction. ITSM manages the processes through which IT services are designed, delivered, operated, and supported.

Integrating IT security into ITSM ensures that security requirements are incorporated into routine IT activities rather than treated as separate technical tasks. It helps organizations maintain secure configurations, control changes, manage incidents, protect information, and preserve service availability.

Relationship Between IT Security and ITSM

IT security and ITSM have complementary responsibilities. ITSM establishes the processes for managing IT services, while IT security defines and supports the protection requirements that must be applied throughout those processes.

For example, Change Management ensures that changes to IT services are assessed, authorized, and implemented in a controlled manner. Security considerations help determine whether those changes introduce vulnerabilities, weaken existing controls, or create additional risks.

By integrating security into ITSM, organizations can improve operational consistency, reduce security risks, support compliance obligations, and maintain the confidentiality, integrity, and availability of IT services and information.

IT Security and ITSM Services Working Together

Service Management System and Service Lifecycle

Overview

A Service Management System (SMS) is the set of policies, objectives, processes, resources, and responsibilities an organization uses to establish, operate, maintain, and continually improve its IT service management capabilities.

The service lifecycle encompasses the activities required to identify service requirements, design and transition services, deliver and support them, and improve their performance throughout their operational life.

Security Considerations

Security requirements should be incorporated into the service management system and considered throughout the service lifecycle. Responsibilities for security, risk assessment, access control, information protection, incident handling, and service continuity should be defined and integrated into relevant service management activities.

Examples

An organization establishes a service management system for its enterprise applications.

• Security Requirements: The organization defines security requirements for authentication, access control, data protection, and service availability.
• Service Design: Security requirements are incorporated into application architecture and service design.
• Service Transition: Security testing and configuration validation are performed before the application enters production.
• Service Operation: Access permissions, system health, and security events are monitored according to established procedures.
• Continual Improvement: Audit findings, incidents, and service performance reports are used to improve service management and security controls.

Service Portfolio and Service Catalogue Management

Overview

Service Portfolio Management oversees the IT services an organization plans, develops, operates, or retires. Service Catalogue Management maintains information about available IT services, including their purpose, service owners, users, dependencies, and applicable service arrangements.

These practices help organizations understand the services they provide and ensure that users and stakeholders have accurate information about service availability and delivery.

Security Considerations

Security requirements should be identified when services are proposed, assessed, introduced, or retired. Service catalogue entries should communicate relevant security responsibilities, access requirements, data-handling restrictions, and service dependencies where appropriate. Sensitive technical information should not be exposed through publicly accessible service catalogues.

Examples

An organization introduces a cloud-based document management service.

• Service Assessment: The service owner evaluates the business purpose, data sensitivity, supplier risks, and security requirements.
• Service Catalogue: The catalogue records the service owner, intended users, support arrangements, and access request procedure.
• Access Restrictions: The service is made available only to authorized user groups.
• Service Retirement: When the service is retired, the organization revokes access, addresses data retention requirements, and ensures that information is securely transferred or disposed of as appropriate.

Business Analysis and Service Requirements

Overview

Business Analysis identifies business needs, evaluates problems and opportunities, and translates stakeholder expectations into requirements for IT services, systems, and solutions. It helps ensure that IT services address business objectives and meet operational expectations.

Security Considerations

Security, privacy, regulatory, and operational requirements should be identified during requirements analysis. These may include authentication, authorization, data protection, audit logging, availability, retention, and recovery requirements. Identifying these requirements early helps prevent costly redesign and reduces the likelihood of security gaps.

Examples

A financial services organization plans to introduce an online customer application.

• Business Requirements: Business analysts document the required customer services and expected functionality.
• Security Requirements: Requirements include multifactor authentication for appropriate access scenarios, role-based authorization, encryption, and audit logging.
• Regulatory Requirements: Applicable data protection and financial-sector obligations are identified.
• Acceptance Criteria: Security requirements are included in the conditions that must be satisfied before the application is accepted.

Service Design and Security Requirements

Overview

Service Design defines how an IT service will meet business and user requirements. It considers service architecture, technology, processes, people, suppliers, support arrangements, capacity, availability, and service continuity.

Security Considerations

Security should be incorporated into service design rather than added only after implementation. Design activities should address identity and access management, network segmentation, secure configurations, encryption, logging, vulnerability management, backup, and recovery requirements according to the service’s risks.

Examples

An organization designs a new customer-facing web application.

• Architecture Design: The application is designed with appropriate separation between its presentation, application, and database layers.
• Identity and Access: Administrative access is restricted to authorized personnel and protected with multifactor authentication.
• Data Protection: Sensitive information is encrypted in transit and at rest where appropriate.
• Monitoring: Application and infrastructure logging requirements are defined.
• Resilience: Backup and recovery arrangements are established according to business requirements.
• Security Validation: The design is reviewed against the organization’s security architecture and applicable requirements before implementation.

Change Management

Overview

Change Management governs how changes to IT infrastructure, applications, configurations, and services are requested, assessed, approved, implemented, and reviewed. It helps minimize disruption to IT services and business operations.

Security Considerations

Security requirements must be considered throughout the change lifecycle. Changes should be assessed for security risks, reviewed against applicable security requirements, and authorized by the appropriate stakeholders. Security testing, access restrictions, and rollback plans should be incorporated where applicable.

Examples

An organization plans to upgrade the firmware of its internet-facing firewall.

• Change Request: The infrastructure team raises a change request documenting the purpose, scope, implementation steps, and expected impact.
• Security Assessment: The security team assesses the potential impact on firewall rules, VPN connectivity, and existing security controls.
• Approval: The change is reviewed and approved by the authorized stakeholders.
• Implementation: The infrastructure team performs the upgrade during the approved maintenance window.
• Security Validation: The security team verifies that firewall policies, VPN connectivity, and security controls continue to operate as intended.
• Rollback: If the upgrade causes a security issue or service disruption, the team follows the documented rollback plan.
• Documentation: The team updates the relevant configuration records and change documentation.

Incident Management

Overview

Incident Management restores normal service operation as quickly as practical following an unplanned interruption, reduction in service quality, or other service-related incident. It focuses on minimizing business impact and restoring the agreed level of service.

Security Considerations

Security-related incidents should be identified and escalated to the appropriate security personnel. The response must balance service restoration with the need to contain threats, preserve evidence, protect sensitive information, and meet applicable reporting obligations. IT service incidents and cybersecurity incidents may overlap, but their handling can require different procedures and specialist responsibilities.

Examples

Employees cannot access an organization’s business application because of suspicious authentication activity.

• Incident Recording: The service desk records the service disruption and gathers relevant information.
• Initial Assessment: The support team identifies unusual authentication failures and escalates the incident to the security team.
• Containment: The security team determines whether accounts or sessions need to be restricted to prevent unauthorized access.
• Service Restoration: The application team restores access after the security issue has been addressed.
• Validation: The teams verify that the application is functioning correctly and that unauthorized access has been contained.
• Documentation: The incident record captures the impact, response, resolution, and required follow-up actions.

Problem Management

Overview

Problem Management identifies and manages the underlying causes of incidents. It aims to reduce the likelihood and impact of recurring incidents by investigating root causes, identifying workarounds, and implementing permanent solutions where appropriate.

Security Considerations

Recurring security-related incidents should be investigated to determine whether they result from vulnerabilities, insecure configurations, inadequate access controls, unsupported software, or weaknesses in operational procedures. Root-cause analysis should lead to corrective actions that reduce the likelihood of recurrence.

Examples

A server repeatedly experiences unauthorized login attempts because of weak administrative access controls.

• Problem Identification: The IT operations team identifies repeated incidents involving suspicious login attempts.
• Root-Cause Analysis: The security team determines that administrative access is exposed and insufficiently restricted.
• Corrective Action: The organization restricts administrative access, strengthens authentication, and reviews privileged accounts.
• Validation: The team verifies that the revised controls are effective.
• Prevention: The organization updates its server-hardening standards and reviews other systems for the same weakness.

Service Request Management

Overview

Service Request Management handles predefined requests initiated by users, such as requests for access, software installation, equipment, information, or standard IT services. It provides a consistent process for submitting, approving, fulfilling, and tracking these requests.

Security Considerations

Requests involving access, software, equipment, or sensitive information should be authenticated, authorized, and fulfilled according to established policies. Approval requirements should reflect the sensitivity of the requested resource and the privileges involved.

Examples

An employee requests access to a financial reporting application.

• Request Submission: The employee submits a service request through the organization’s service portal.
• Identity Verification: The service desk verifies the employee’s identity.
• Authorization: The employee’s manager or designated application owner approves the request as required.
• Access Provisioning: The IT team assigns the appropriate role without granting unnecessary privileges.
• Validation: The team confirms that the employee can access only the permitted functions.
• Record Keeping: The request and approval are recorded for auditing and future access reviews.

Service Configuration Management

Overview

Service Configuration Management maintains information about configuration items and their relationships. Configuration items may include servers, network devices, applications, databases, cloud resources, and other components required to deliver IT services.

The information is commonly maintained in a Configuration Management Database (CMDB) or another configuration management system.

Security Considerations

Accurate configuration information helps security teams understand system dependencies, identify affected assets, investigate incidents, and assess the impact of changes. Configuration records should be protected against unauthorized modification, and discrepancies between documented and actual configurations should be investigated.

Examples

An organization maintains configuration records for its production web application.

• Configuration Records: The CMDB records the application servers, database servers, network dependencies, and service relationships.
• Access Protection: Permissions restrict who can view or modify sensitive configuration records.
• Change Tracking: Approved changes are reflected in the configuration records.
• Security Assessment: When a vulnerability affects a particular server version, the organization uses configuration information to identify potentially affected systems.
• Validation: The team compares recorded configurations with actual system configurations and investigates unauthorized changes.

IT Asset Management

Overview

IT Asset Management manages IT assets throughout their lifecycle, from acquisition and deployment to maintenance, reassignment, and disposal. Assets may include hardware, software, licenses, endpoints, servers, network equipment, and cloud resources.

Security Considerations

Asset information supports security by identifying what must be protected, who owns each asset, where it is deployed, and whether it remains supported. Asset management should support the identification of unauthorized software, unpatched systems, end-of-life equipment, and assets that require secure disposal.

Examples

An organization discovers that several employee laptops are running unsupported operating systems.

• Asset Identification: The asset register identifies the affected laptops, their assigned users, and their operating system versions.
• Risk Assessment: The security team evaluates the risks associated with unsupported systems.
• Remediation: The organization upgrades the operating systems or replaces the affected devices.
• Access Protection: Devices that cannot be remediated immediately may be restricted from sensitive services according to the organization’s risk decisions.
• Secure Disposal: Retired laptops undergo approved data sanitization before disposal or reassignment.
• Record Updates: The asset register is updated to reflect the changes.

Release Management

Overview

Release Management plans, schedules, and controls the availability of new or changed services and service components. It coordinates the introduction of releases so that changes can be delivered in a controlled and predictable manner.

Security Considerations

Releases should be assessed against applicable security requirements before they are made available. Security testing, dependency reviews, release authorization, artifact integrity, and deployment readiness should be incorporated according to the risks associated with the release.

Examples

An organization prepares a new release of its customer portal.

• Release Planning: The release team identifies the included application changes and dependencies.
• Security Review: The security team reviews vulnerability scan results and relevant security test findings.
• Approval: Outstanding security issues are assessed, and release approval is granted according to established acceptance criteria.
• Artifact Protection: Release packages are stored in an access-controlled repository.
• Release Validation: The team confirms that the approved version is the one being released.
• Post-Release Review: The organization monitors the service for unexpected behavior and security-related issues.

Deployment Management

Overview

Deployment Management moves new or changed service components into target environments. It coordinates the installation, configuration, and activation of infrastructure, applications, and other components required to deliver IT services.

Security Considerations

Deployments should use authorized tools, approved artifacts, controlled administrative access, and secure configuration baselines. Environment separation and deployment validation help reduce the risk of unauthorized changes, misconfiguration, and exposure of sensitive information.

Examples

An organization deploys a new application server into its production environment.

• Deployment Authorization: The deployment team confirms that the change and release have the required approvals.
• Access Control: Only authorized administrators and deployment services can modify the production environment.
• Secure Configuration: The server is configured according to the approved hardening baseline.
• Software Validation: The team verifies the integrity and approved version of the deployed software.
• Security Testing: The server is checked for required security settings and unnecessary exposed services.
• Deployment Verification: The team confirms that the application operates correctly and that security controls remain effective.

Service Validation and Testing

Overview

Service Validation and Testing verifies that a new or changed service meets defined requirements and is suitable for its intended use. It helps establish that the service can operate as expected before acceptance or release.

Security Considerations

Testing should verify applicable security requirements alongside functional and operational requirements. Depending on the service and its risks, this may include vulnerability assessment, access control testing, configuration validation, software security testing, and verification of backup and recovery capabilities.

Examples

An organization prepares a new employee self-service application.

• Requirements Review: The testing team identifies the functional and security acceptance criteria.
• Access Control Testing: Testers verify that employees can access only their permitted records and functions.
• Vulnerability Testing: The application is assessed for relevant security weaknesses.
• Configuration Validation: The team checks that security settings match the approved baseline.
• Defect Resolution: Identified security issues are recorded, prioritized, and addressed.
• Acceptance: The service is accepted only when the applicable acceptance criteria have been met or exceptions have been formally assessed and approved.

Service Desk Management

Overview

Service Desk Management provides a central point of contact for users who need assistance with IT services. The service desk records and coordinates incidents and service requests, communicates service status, and helps users obtain the support they need.

Security Considerations

Service desk procedures should protect user identities and sensitive information. Staff should verify identities before performing sensitive actions, follow authorization requirements for access changes, protect support records, and escalate suspected security incidents through the appropriate channels.

Examples

An employee contacts the service desk to reset a password.

• Identity Verification: The service desk verifies the employee’s identity using the approved procedure.
• Request Validation: The agent confirms that the request meets the password-reset requirements.
• Secure Execution: The password reset is completed through the authorized process without disclosing credentials to the employee or others.
• Suspicious Activity: If the request appears fraudulent or is associated with unusual account activity, the agent escalates it to the security team.
• Record Keeping: The service desk records the action without unnecessarily exposing sensitive authentication information.

Service Level Management

Overview

Service Level Management defines, agrees, monitors, and reviews service level expectations between service providers and customers or business stakeholders. It helps ensure that service performance and support arrangements align with business needs.

Security Considerations

Service agreements should include security-related commitments where appropriate. These may cover incident notification, access management, service availability, backup and recovery, vulnerability remediation, and regulatory obligations. Security commitments should be measurable and aligned with the organization’s risk tolerance and contractual responsibilities.

Examples

An organization establishes a service-level agreement for a business-critical application.

• Service Requirements: The service owner identifies availability and support requirements.
• Security Commitments: The agreement defines relevant security incident escalation and notification expectations.
• Performance Monitoring: The service team measures agreed availability and response targets.
• Incident Reporting: Security-related service disruptions are reported through the defined escalation process.
• Review: Service performance and security-related metrics are reviewed with the relevant stakeholders.

Availability Management

Overview

Availability Management ensures that IT services meet agreed availability requirements. It considers service reliability, resilience, maintenance, dependencies, and the ability to recover from failures.

Security Considerations

Security threats and control failures can affect service availability. Availability planning should consider denial-of-service attacks, ransomware, unauthorized configuration changes, infrastructure failures, and other threats that may interrupt service delivery. Protective measures should be proportionate to business impact and risk.

Examples

An organization operates a business-critical online payment service.

• Availability Requirements: The service owner defines the required availability and recovery expectations.
• Risk Assessment: The team assesses threats such as denial-of-service attacks, infrastructure failures, and malicious changes.
• Protective Controls: Appropriate network protections, access controls, redundancy, and monitoring are implemented.
• Failure Detection: The operations team monitors service health and availability indicators.
• Recovery: If a disruption occurs, the team follows the relevant restoration procedures.
• Review: The organization examines outages and security-related disruptions to identify improvements.

Capacity and Performance Management

Overview

Capacity and Performance Management ensures that IT services have sufficient resources to meet current and anticipated demand while delivering acceptable performance. It considers computing, storage, network, application, and other resource requirements.

Security Considerations

Capacity and performance planning should account for resource exhaustion and abnormal demand that may indicate a security incident. Monitoring should identify unexpected increases in CPU, memory, storage, network traffic, or application requests. Capacity controls should also protect against service degradation caused by resource abuse.

Examples

An organization experiences unusually high traffic against its public-facing application.

• Performance Monitoring: The operations team identifies an unexpected increase in requests and resource utilization.
• Investigation: The team determines whether the increase is legitimate demand, a configuration problem, or potentially malicious activity.
• Security Coordination: If attack activity is suspected, the security team investigates and coordinates appropriate protective measures.
• Capacity Response: The operations team adjusts capacity or applies approved traffic-management measures.
• Validation: The teams verify that service performance has recovered and relevant risks have been addressed.

Service Continuity Management

Overview

Service Continuity Management prepares the organization to maintain or restore IT services following major disruptions. It involves identifying continuity requirements, planning recovery arrangements, and testing the organization’s ability to resume critical services.

Security Considerations

Continuity planning should account for cyber incidents such as ransomware, destructive attacks, compromise of administrative accounts, and loss of critical infrastructure. Backup protection, recovery access controls, isolated recovery environments, and tested restoration procedures help reduce the risk of an attacker compromising both production systems and recovery capabilities.

Examples

An organization develops continuity arrangements for its enterprise systems.

• Business Impact Analysis: The organization identifies critical services and determines recovery priorities.
• Recovery Planning: Recovery procedures and responsibilities are documented.
• Backup Protection: Backups are protected against unauthorized access and modification.
• Recovery Access: Administrative credentials required for recovery are securely managed.
• Recovery Testing: The organization tests restoration procedures in a controlled environment.
• Improvement: Findings from exercises and incidents are used to strengthen continuity arrangements.

Monitoring and Event Management

Overview

Monitoring and Event Management observes IT services and infrastructure to identify changes in service state, performance, availability, and operational conditions. It helps teams detect issues, assess their significance, and initiate appropriate responses.

Security Considerations

Operational monitoring can support cybersecurity by identifying unusual system behavior, unexpected configuration changes, resource exhaustion, and events that may indicate a security issue. Security-focused detection and investigation should be coordinated with the organization’s dedicated security monitoring and incident response capabilities.

Examples

An organization monitors its production server environment.

• Monitoring Setup: The operations team configures monitoring for server health, service availability, storage, and network performance.
• Event Detection: The monitoring system identifies an unexpected increase in failed authentication attempts and unusual resource consumption.
• Initial Assessment: The operations team determines whether the event affects service performance or availability.
• Security Escalation: Suspicious activity is referred to the security team for investigation.
• Service Response: The operations team takes approved actions to maintain or restore service operation.
• Review: The teams review the event and improve monitoring or operational procedures where needed.

Knowledge Management

Overview

Knowledge Management maintains and shares information required to deliver, support, and improve IT services. It includes operational procedures, troubleshooting guides, known errors, service documentation, and other information that helps teams perform their responsibilities consistently.

Security Considerations

Knowledge repositories may contain sensitive operational information, including network diagrams, system configurations, recovery procedures, and administrative instructions. Access should be restricted according to the sensitivity of the information, and documentation should be kept accurate and protected against unauthorized disclosure or modification.

Examples

An organization maintains a knowledge base for IT support and infrastructure teams.

• Documentation: The team records approved troubleshooting procedures and system recovery instructions.
• Access Restrictions: Sensitive infrastructure diagrams and administrative procedures are accessible only to authorized personnel.
• Credential Protection: Passwords, secret keys, and other authentication material are stored in approved secure systems rather than ordinary knowledge articles.
• Review: Documentation owners periodically verify that procedures remain accurate.
• Retirement: Outdated instructions are withdrawn to prevent unsafe or insecure operational practices.

Supplier Management

Overview

Supplier Management manages relationships with external providers that deliver products or services to the organization. It helps ensure that suppliers meet agreed service, performance, contractual, and operational requirements.

Security Considerations

Supplier relationships should be assessed for risks involving access to systems, handling of organizational data, service dependencies, subcontractors, and supply-chain vulnerabilities. Contracts and service agreements should establish appropriate security responsibilities, access restrictions, incident notification expectations, and service continuity arrangements.

Examples

An organization engages a third-party provider to manage its cloud infrastructure.

• Supplier Assessment: The organization evaluates the provider’s service capabilities and relevant security risks.
• Contractual Requirements: Security responsibilities, data handling, incident notification, and access requirements are documented.
• Access Control: The provider receives only the access necessary to perform its contracted responsibilities.
• Monitoring: The organization reviews service performance and relevant security assurance information.
• Incident Coordination: Procedures define how the supplier reports and coordinates security incidents affecting the service.
• Termination: When the contract ends, access is revoked and organizational data is returned or disposed of according to the agreement and applicable requirements.

Infrastructure and Platform Management

Overview

Infrastructure and Platform Management manages the technology platforms that support IT services, including servers, operating systems, networks, virtualization environments, cloud platforms, storage, and related infrastructure components.

Security Considerations

Infrastructure management should incorporate secure configuration, vulnerability remediation, privileged access controls, network segmentation, logging, backup, and lifecycle management. Standardized configurations and controlled administrative procedures help reduce exposure to common infrastructure weaknesses.

Examples

An organization manages its virtualized server environment.

• Secure Configuration: Hypervisors and virtual machines are configured according to approved security baselines.
• Administrative Access: Access to management interfaces is restricted to authorized administrators and protected with strong authentication.
• Patch Management: Security updates are assessed and applied according to risk and change procedures.
• Network Segmentation: Management interfaces are separated from ordinary user networks where appropriate.
• Monitoring: Infrastructure health and relevant security events are monitored.
• Validation: Periodic reviews identify configuration drift and unauthorized changes.

Software Development and Management

Overview

Software Development and Management covers the development, maintenance, and management of software used to deliver IT services. It includes requirements, design, coding, testing, release preparation, maintenance, and software lifecycle activities.

Security Considerations

Security should be integrated into the software lifecycle through secure design, coding standards, code review, dependency management, security testing, vulnerability remediation, and controlled release practices. Development, testing, and production environments should be appropriately separated, and sensitive data should be protected throughout development and testing.

Examples

An organization develops an internal employee application.

• Secure Requirements: The development team documents authentication, authorization, data protection, and logging requirements.
• Secure Coding: Developers follow approved coding standards and review code for common vulnerabilities.
• Dependency Management: Third-party libraries are assessed for known vulnerabilities.
• Security Testing: The application undergoes relevant automated and manual security testing.
• Secrets Protection: Credentials and API keys are stored in approved secret-management systems rather than embedded in source code.
• Release Control: The approved application version is deployed through the organization’s controlled release and deployment processes.
• Maintenance: Vulnerabilities discovered after release are assessed and remediated according to risk.

Information Security Management

Overview

Information Security Management establishes and maintains the policies, responsibilities, processes, and controls required to protect information and support the secure delivery of IT services. Within ITSM, it ensures that information security requirements are incorporated into service management activities.

Security Considerations

Security responsibilities should be defined across service owners, IT operations, service management, and security teams. Information security requirements should be reflected in service design, access management, change processes, incident handling, supplier management, and service continuity. This integration should align with the organization’s broader security governance and information security management arrangements.

Examples

An organization integrates information security requirements into its service management system.

• Defined Responsibilities: The organization establishes responsibilities for service owners, IT operations, and the security team.
• Policy Integration: Relevant security policies are reflected in service management procedures.
• Access Control: Service processes require appropriate authorization for access provisioning and changes.
• Incident Coordination: Service management procedures define how suspected security incidents are escalated.
• Compliance Evidence: Records of approvals, changes, incidents, and reviews are maintained to support applicable audit requirements.
• Improvement: Audit findings and operational lessons are used to improve security integration across ITSM.

IT Risk Management

Overview

IT Risk Management identifies, assesses, treats, and monitors risks that could affect IT services, supporting infrastructure, and service delivery. It helps organizations make informed decisions about risk exposure and prioritize appropriate treatment measures.

Security Considerations

Within ITSM, risk management should consider operational and service-related risks, including service disruption, supplier dependency, configuration errors, unsupported technology, and security weaknesses. Risks should be assessed using the organization’s established risk management approach, with clear ownership, treatment decisions, and escalation procedures.

Examples

An organization identifies a risk associated with an unsupported operating system that hosts a critical business service.

• Risk Identification: The service owner records the unsupported operating system as a risk.
• Impact Assessment: The team evaluates the potential impact of exploitation, service disruption, and data exposure.
• Risk Treatment: The organization plans an upgrade or migration to a supported platform.
• Interim Controls: Until remediation, additional restrictions and monitoring are applied where appropriate.
• Risk Ownership: A designated owner tracks the treatment plan and any approved residual risk.
• Review: The risk record is updated after remediation and validation.

Service Measurement and Reporting

Overview

Service Measurement and Reporting collects, analyzes, and communicates information about service performance, quality, effectiveness, and compliance with agreed requirements. It helps stakeholders evaluate whether IT services are meeting business and operational expectations.

Security Considerations

Service reports should include relevant security indicators where appropriate, such as unresolved vulnerabilities, security-related incidents, access review completion, patching status, and compliance with security requirements. Metrics should be clearly defined, meaningful, and protected against unauthorized disclosure or alteration.

Examples

An organization prepares a monthly report for a business-critical IT service.

• Metric Definition: The service owner defines relevant operational and security measures.
• Data Collection: Service records, monitoring systems, vulnerability reports, and change records provide supporting data.
• Performance Analysis: The team reviews availability, incident trends, and outstanding security issues.
• Risk Escalation: Significant deviations or overdue security actions are escalated to the responsible stakeholders.
• Reporting: Results are communicated to service owners and management.
• Improvement Tracking: Corrective actions are assigned and monitored.

Continual Improvement

Overview

Continual Improvement systematically identifies and implements opportunities to improve IT services, service management processes, and operational outcomes. It uses performance information, feedback, incidents, assessments, and lessons learned to identify areas where changes can provide measurable benefits.

Security Considerations

Security improvement should be informed by incidents, vulnerability assessments, audits, control testing, threat information, and changes in business or technology requirements. Improvement actions should have clear owners, priorities, target dates, and verification criteria.

Examples

An organization identifies recurring security configuration weaknesses across its server environment.

• Opportunity Identification: Audit findings and configuration assessments reveal repeated deviations from approved baselines.
• Root-Cause Review: The infrastructure and security teams determine why the deviations occur.
• Improvement Plan: The organization updates server build templates and configuration management procedures.
• Implementation: Revised templates are introduced through controlled change and deployment processes.
• Effectiveness Testing: Follow-up assessments verify that the recurring weaknesses have been reduced.
• Ongoing Review: Configuration compliance is measured regularly, and further improvements are introduced when necessary.

IT Security Monitoring

IT Security Monitoring involves the ongoing observation, assessment, and review of security controls, configurations, access privileges, security technologies, and remediation activities to determine whether they meet the organization’s security requirements.

In an enterprise environment, security monitoring involves collaboration between the Security Operations Center (SOC), IT Security, and IT Operations teams. Each team has a distinct responsibility in identifying security issues, coordinating responses, implementing corrective actions, and verifying that security requirements are satisfied.

The SOC primarily monitors security events, detects suspicious activities, investigates alerts, and reports or escalates security incidents. IT Security coordinates incident remediation across teams, monitors security control effectiveness, and tracks unresolved security risks. The responsible IT teams remediate issues affecting the technologies and services they manage, while IT Security teams may directly remediate issues involving security technologies under their ownership.

IT Security Monitoring therefore extends beyond threat detection. It also evaluates security control implementation, identifies configuration deficiencies, monitors remediation progress, and provides assurance that security issues are addressed appropriately.

SOC and IT Security Roles in Security Monitoring

Security monitoring requires a clear division of responsibilities between the SOC and IT Security. Although their activities are closely related, their primary objectives differ.

Security Operations Center (SOC)

The SOC is responsible for monitoring security events, detecting suspicious activities, investigating alerts, and identifying potential security incidents. It uses security monitoring technologies, event correlation, and threat intelligence to identify activities that could compromise the confidentiality, integrity, or availability of organizational systems and information.

The SOC typically performs the following activities:

• Security Event Monitoring: Monitors security events from networks, endpoints, applications, identity systems, cloud environments, and other relevant sources.
• Threat Detection: Identifies suspicious activities, potential attacks, indicators of compromise, and other security threats.
• Alert Investigation: Analyzes alerts, correlates events, and gathers evidence to determine whether suspicious activity represents a potential security incident.
• Incident Reporting: Creates or updates incident records with relevant evidence, affected assets, severity, and recommended response actions.
• Incident Escalation: Escalates incidents to IT Security, incident response personnel, or the responsible IT teams according to established procedures.
• Threat Hunting: Proactively investigates systems and security telemetry to identify suspicious activity that may not have triggered existing detection rules.
• Incident Validation: Supports verification that suspicious activity has stopped and that the identified threat is no longer present, where this responsibility is assigned to the SOC.

The SOC’s primary responsibility is security event monitoring, detection, investigation, and reporting. Its involvement in containment, remediation, recovery, and closure depends on the organization’s security operating model.

IT Security Team

The IT Security team coordinates security incident remediation, oversees security control implementation, and monitors whether security requirements are being maintained across the IT environment.

The team acts as a coordination point between the SOC and the IT teams responsible for affected systems, applications, networks, endpoints, and cloud services.

Its responsibilities typically include:

• Incident Coordination: Coordinates remediation activities between the SOC and the responsible IT teams.
• Incident Assignment: Helps ensure that incidents are assigned to the appropriate technical team based on the affected technology and ownership responsibilities.
• Remediation Tracking: Tracks corrective actions, target dates, service-level agreements (SLAs), and unresolved security findings.
• Escalation Management: Escalates delayed remediation, unresolved control deficiencies, and significant security risks to the appropriate stakeholders.
• Security Control Monitoring: Reviews whether security controls are implemented, configured, and operating in accordance with established requirements.
• Security Technology Remediation: Directly remediates issues involving security technologies managed by IT Security, such as firewalls, web application firewalls (WAFs), and endpoint detection and response (EDR) platforms.
• Remediation Verification: Reviews supporting evidence and confirms that required security conditions have been satisfied, where verification is part of its assigned responsibilities.
• Security Reporting: Reports control deficiencies, outstanding risks, overdue remediation, and security performance to IT Security leadership and relevant stakeholders.

IT Security does not necessarily perform every remediation activity. For example, if the SOC detects a compromised server, IT Security coordinates with the team responsible for that server. If the incident requires correcting a firewall rule managed by IT Security, the designated IT Security team may perform the correction directly.

This division of responsibilities helps ensure that incidents are addressed by the appropriate technical teams while maintaining security oversight and accountability.

IT Operations Teams and Security Incident Handling

IT Operations teams are responsible for operating, maintaining, and supporting the IT systems and services assigned to them. When a security incident affects these systems, the responsible team receives the incident, performs technical triage, implements corrective actions, and supports recovery.

The specific activities depend on the affected technology, the nature of the incident, and the organization’s assigned responsibilities.

The general incident handling workflow consists of the following stages.

Incident Receipt and Assignment

When the SOC identifies a potential security incident, it creates or escalates an incident record and routes it to the appropriate response or remediation team.

IT Security may coordinate the assignment when an incident involves multiple teams, the responsible owner is unclear, or security oversight is required.

The incident record should contain sufficient information for the receiving team to understand the issue and begin the required investigation.

Typical information includes:

• Incident description and detection source.
• Affected systems, assets, users, or business services.
• Incident severity and potential business impact.
• Relevant alerts, logs, indicators, and investigation findings.
• Recommended containment or remediation actions.
• Response priorities and applicable SLAs.
• Contact details for the incident coordinator or reporting team, where appropriate.

The receiving team acknowledges the incident and accepts responsibility for the actions assigned to it. If the incident has been assigned incorrectly, the team should route it to the appropriate owner rather than allowing it to remain unassigned.

Incident Triage and Analysis

Incident triage involves assessing the reported issue, validating the available information, determining its potential impact, and identifying the appropriate technical response.

The SOC typically performs the initial security investigation and provides the relevant findings. The receiving IT team then examines the affected technology to understand the technical condition and determine the actions required within its area of responsibility.

Triage may involve:

• Identifying affected assets and services.
• Reviewing system, application, network, or cloud logs.
• Checking configurations and recent changes.
• Determining whether the issue is ongoing.
• Assessing operational dependencies and business impact.
• Identifying potential containment measures.
• Determining whether additional teams must participate in remediation.

For example, when the SOC reports suspicious outbound traffic from a server, the responsible infrastructure team may examine the server’s processes, connections, and system logs while coordinating with the SOC and IT Security.

Triage should establish the next action and its owner. If new evidence indicates a more serious incident, the issue should be escalated according to the organization’s incident response procedure.

Security Incident Remediation

Remediation involves implementing corrective actions to remove the identified weakness, stop the unwanted activity, or restore the required security condition.

The responsible IT or IT Security team performs the remediation according to the affected technology and its assigned ownership.

Examples include:

• Correcting an insecure firewall rule.
• Updating a WAF policy to address an identified attack path.
• Isolating or remediating a compromised endpoint.
• Applying a security patch to a vulnerable server.
• Correcting an application vulnerability.
• Restricting excessive access privileges.
• Correcting an insecure cloud configuration.
• Disabling an unauthorized account or service.
• Restoring a disabled or incorrectly configured security control.

Remediation must follow the organization’s change management and incident response procedures. Where immediate containment is required, emergency change procedures may apply.

The team performing remediation should document the corrective actions taken, the affected assets, and the evidence needed to demonstrate completion.

Service and System Recovery

Recovery involves restoring affected systems and services to an acceptable operational and security state following containment and remediation.

Recovery may require coordination between IT Operations, IT Security, the SOC, application owners, and business stakeholders.

Activities may include:

• Restoring systems from trusted backups where necessary.
• Rebuilding compromised systems.
• Reapplying approved security configurations.
• Restoring network connectivity and application services.
• Re-enabling security controls after confirming that they are safe to restore.
• Validating system functionality and service availability.
• Monitoring recovered systems for signs of renewed suspicious activity.

Recovery should not be treated as complete merely because a system is operational again. The organization should confirm that the original security issue has been addressed and that required security controls are functioning.

Incident Verification and Closure

Incident verification determines whether the corrective actions were successful and whether the required security conditions have been restored.

The remediation team provides evidence of the work completed. The SOC may validate that suspicious activity has stopped, while IT Security may verify security control compliance or review the remediation evidence. The exact verification responsibilities depend on the incident and the organization’s operating model.

Verification activities may include:

• Rechecking the affected configuration.
• Confirming that a security patch has been installed.
• Validating that unauthorized access has been removed.
• Confirming that an EDR agent is connected and enforcing the required policy.
• Reviewing firewall or WAF changes.
• Repeating a vulnerability scan or other appropriate technical test.
• Confirming that the affected service has recovered securely.
• Checking for recurrence of the original suspicious activity.

The designated incident owner closes the incident according to the organization’s incident management procedure once the required closure criteria have been met.

If remediation is incomplete or verification fails, the incident should remain open or be returned for further action. Any unresolved risk must be documented and managed through the appropriate risk acceptance or exception process.

IT Security Monitoring Objectives

IT Security Monitoring helps organizations maintain effective security controls, coordinate incident remediation, and ensure that identified security weaknesses are addressed in accordance with established requirements.

Its primary objectives include the following.

Maintaining Security Control Effectiveness

Monitoring determines whether security controls continue to operate as intended and meet approved security requirements.

For example, IT Security may review firewall configurations, EDR deployment coverage, privileged access restrictions, and cloud security configurations.

Identifying Security Control Deficiencies

Monitoring helps identify missing controls, insecure configurations, incomplete security technology coverage, and deviations from approved policies or standards.

Identified deficiencies should be assessed for risk and assigned for corrective action.

Coordinating Security Incident Remediation

Monitoring helps ensure that security incidents are assigned to the appropriate teams, tracked against defined priorities, and escalated when remediation is delayed or unsuccessful.

Reducing Security Risk Exposure

Monitoring known vulnerabilities, configuration weaknesses, and unresolved control deficiencies helps reduce the time that security risks remain unaddressed.

Remediation priorities should reflect the severity of the issue, exposure, asset criticality, business impact, and applicable requirements.

Maintaining Security Technology Coverage

Monitoring helps confirm that required security technologies remain deployed, operational, and appropriately configured across the intended environment.

Supporting Security Governance and Compliance

Monitoring produces evidence of security control implementation, identified deficiencies, remediation progress, and outstanding risks. This evidence supports internal reviews, audits, compliance activities, and management reporting.

Improving Security Performance

Reviewing metrics and recurring findings helps IT Security identify persistent weaknesses, assess remediation performance, and recommend improvements to controls and processes.

Security Incident Coordination and Escalation

Security incident coordination establishes how incidents are communicated, assigned, tracked, escalated, and resolved across the SOC, IT Security, and the responsible IT teams.

Clear coordination helps prevent incidents from remaining unassigned, being handled by multiple teams without ownership, or being closed without adequate remediation evidence.

Incident Prioritization

Incidents should be prioritized according to severity, potential business impact, affected asset criticality, exposure, and the likelihood of further compromise.

A confirmed compromise of a critical internet-facing server may require immediate containment, while a lower-risk configuration deviation may be addressed through a planned remediation process.

The organization should define its incident severity levels and response expectations so that teams apply consistent priorities.

Remediation Ownership

Each incident requiring corrective action should have a clearly identified owner.

The owner is generally the team responsible for the affected technology or service. IT Security coordinates remediation where cross-team involvement or security oversight is required.

Where responsibilities overlap, IT Security should help establish the lead remediation team and clarify the actions assigned to each participating team.

Incident Escalation

Incidents should be escalated when:

• Required response or remediation deadlines are exceeded.
• The severity or scope of the incident increases.
• Containment or remediation is unsuccessful.
• Additional technical teams or business owners must participate.
• A security control cannot be restored as required.
• The residual risk exceeds the team’s authority to accept.
• Business services may be significantly affected.

Escalation may involve IT Security leadership, technical service owners, the CISO, business management, or designated incident response leadership, depending on the circumstances.

Communication and Status Reporting

The incident coordinator should ensure that the relevant teams receive timely updates about the incident status, actions completed, outstanding tasks, dependencies, and expected resolution.

For significant incidents, updates may also be required by business stakeholders and senior management.

Incident Closure Governance

The organization should define the conditions for incident closure, including required remediation evidence, verification, approvals, and documentation.

The team performing remediation does not automatically have sole authority to close every incident. Closure must follow the assigned incident management responsibilities and procedures.

IT Security Control Monitoring

IT Security Control Monitoring evaluates whether security controls are implemented, configured, maintained, and operating in accordance with approved requirements.

Unlike SOC monitoring, which primarily focuses on security events and potential threats, control monitoring assesses the condition and effectiveness of the security measures intended to protect the IT environment.

Control Implementation Monitoring

IT Security reviews whether required controls have been deployed across the assets and environments within their scope.

Examples include confirming that EDR is deployed on required endpoints, network security controls are implemented at designated boundaries, privileged access is restricted, and cloud environments have the required security protections.

Control Configuration Monitoring

Security controls must be configured according to approved baselines, architecture requirements, and organizational policies.

IT Security may review firewall rules, endpoint protection policies, authentication requirements, encryption settings, logging configurations, and other security parameters.

Deviations should be recorded, assessed for risk, and assigned for remediation or formally approved as exceptions where justified.

Control Coverage Monitoring

Control coverage measures whether required assets are protected by the designated security controls.

For example, an organization may have deployed EDR across most endpoints but still have servers or workstations outside the management and protection scope.

Monitoring helps identify these gaps and ensures that the responsible teams address them.

Control Effectiveness Monitoring

Control effectiveness monitoring determines whether implemented controls achieve their intended objectives.

This may involve reviewing configuration evidence, examining control operation, analyzing assessment results, and validating corrective actions.

A control may be installed but ineffective because it is disabled, misconfigured, improperly maintained, or not applied to all required assets.

Security Configuration and Compliance Monitoring

Security Configuration and Compliance Monitoring evaluates whether IT assets and services comply with approved security baselines, internal policies, technical standards, and applicable external requirements.

Configuration deviations can introduce weaknesses, increase exposure, and undermine security controls.

Security Baseline Compliance

IT Security establishes or oversees security configuration requirements in collaboration with technical teams and architecture stakeholders.

These requirements may cover operating systems, network devices, endpoints, applications, databases, virtualization platforms, and cloud services.

Monitoring activities may include:

• Reviewing configuration compliance reports.
• Identifying deviations from approved security baselines.
• Verifying that required security settings are enabled.
• Checking for unauthorized or unapproved configuration changes.
• Tracking exceptions and corrective actions.
• Confirming that approved exceptions have appropriate ownership and review dates.

Security Configuration Deviations

A configuration deviation occurs when an asset or service does not comply with an approved security requirement.

For example, a server may permit an insecure protocol, a firewall may contain an unnecessarily permissive rule, or a cloud storage service may allow broader access than intended.

IT Security assesses the significance of the deviation and coordinates remediation with the responsible team.

Not every deviation represents an exploitable vulnerability. Its risk should be assessed in context, including asset criticality, exposure, compensating controls, and business requirements.

Security Compliance Reporting

Compliance monitoring results should be documented and reported to relevant stakeholders.

Reports may identify noncompliant assets, recurring configuration weaknesses, overdue corrective actions, approved exceptions, and areas requiring management attention.

Identity and Access Control Monitoring

Identity and Access Control Monitoring evaluates whether access to organizational systems, applications, data, and infrastructure follows approved identity and access security requirements.

Its objective is to identify excessive privileges, inappropriate access assignments, incomplete access removal, and failures in the implementation of identity security controls.

User and Privileged Access Monitoring

IT Security may review whether user and privileged access rights comply with approved access policies and business requirements.

Monitoring activities can include:

• Reviewing privileged accounts and their assigned permissions.
• Identifying inactive, orphaned, or unnecessary accounts.
• Verifying that access is removed when users leave the organization or change roles.
• Checking whether multi-factor authentication is enforced for required accounts.
• Reviewing access to critical systems and sensitive information.
• Identifying unauthorized changes to roles, groups, or access policies.

Access Control Compliance

Access controls should be assessed against the organization’s identity and access security requirements.

For example, IT Security may verify that privileged access is restricted to authorized administrators, service accounts have appropriate permissions, and access to critical applications follows the required approval process.

Where discrepancies are identified, IT Security coordinates corrective action with the responsible identity management team, application owner, infrastructure team, or other designated party.

Access Review and Remediation

Periodic access reviews help determine whether existing permissions remain necessary and appropriate.

Review findings may result in access removal, privilege reduction, account disablement, or changes to role assignments.

IT Security should track significant findings to completion and ensure that access changes are implemented and documented according to organizational procedures.

Identity and Access Control Monitoring complements SOC monitoring. The SOC may detect suspicious authentication activity, while IT Security monitors whether identity and access controls are correctly implemented and maintained.

Security Technology Health and Coverage Monitoring

Security technologies must remain available, correctly configured, and sufficiently deployed to provide their intended protection. IT Security Monitoring therefore includes oversight of the health and coverage of security technologies managed by IT Security or other designated teams.

Security Technology Availability

Monitoring should identify security technologies that are unavailable, disconnected, disabled, or unable to perform their intended functions.

Examples include:

• Firewalls that are unavailable or operating with degraded functionality.
• EDR agents that are disconnected from their management platform.
• WAF components that are not processing the expected traffic.
• Security management platforms that cannot distribute required policies.
• Security controls that have stopped producing expected logs or telemetry.

Operational ownership may rest with IT Security, IT Operations, or a dedicated security engineering team, depending on the technology and organizational structure.

Security Technology Coverage

Coverage monitoring evaluates whether the required assets are protected by the designated security technologies.

For example, IT Security may compare the organization’s endpoint inventory against the EDR management console to identify endpoints that are missing agents or have not communicated within the expected period.

Similar reviews may be performed for firewall coverage, cloud security controls, vulnerability scanning, identity security, and other technologies.

Security Policy and Configuration Health

Security technologies should be checked to determine whether their policies and configurations remain aligned with approved requirements.

Examples include verifying that required firewall rules are in place, EDR policies are assigned to the correct device groups, WAF protection policies are enabled, and security management platforms apply the expected configurations.

Identified deficiencies should be assigned to the responsible team and tracked until corrected.

Technology Health Reporting

IT Security may report technology availability, deployment coverage, policy compliance, agent connectivity, configuration drift, and outstanding corrective actions.

These measures help distinguish between a security technology that has been purchased or deployed and one that is operationally effective across the intended environment.

Security Remediation Tracking and Verification

Security Remediation Tracking and Verification ensures that identified vulnerabilities, control deficiencies, configuration deviations, and security incidents are assigned, addressed, and verified.

Detection alone does not reduce risk. The organization must ensure that corrective actions are completed and that unresolved issues receive appropriate attention.

Remediation Tracking

IT Security tracks remediation activities identified through SOC incidents, security assessments, compliance reviews, configuration monitoring, vulnerability management, and other security processes.

Tracking information may include:

• Description of the finding or incident.
• Affected assets and business services.
• Severity and assessed risk.
• Assigned remediation team and owner.
• Required corrective action.
• Target completion date or applicable SLA.
• Current status and supporting evidence.
• Dependencies, exceptions, and escalation history.

The remediation owner should be the team responsible for implementing the corrective action. IT Security provides coordination and oversight where required.

Remediation Prioritization

Remediation should be prioritized according to risk rather than treating all findings equally.

Relevant considerations include vulnerability severity, exploitability, exposure, asset criticality, business impact, evidence of active exploitation, and the effectiveness of existing compensating controls.

For example, a critical vulnerability affecting an internet-facing business service may require more urgent attention than a lower-risk finding on an isolated system.

Remediation Verification

Verification determines whether the corrective action has been implemented successfully and addresses the original finding.

Depending on the issue, verification may involve:

• Rechecking the relevant configuration.
• Confirming that a security patch has been installed.
• Validating that an access permission has been removed.
• Confirming that an EDR agent is connected and enforcing the required policy.
• Reviewing firewall or WAF configuration changes.
• Repeating a vulnerability scan or other appropriate technical test.
• Confirming that the original security issue is no longer present.

Verification should be proportionate to the risk and the nature of the corrective action. Where possible, it should use evidence independent of the remediation team’s assertion that the work is complete.

Overdue Remediation and Risk Acceptance

Remediation activities that exceed established deadlines should be reviewed and escalated according to organizational procedures.

If a finding cannot be remediated within the required timeframe, the organization should assess the residual risk and determine whether temporary mitigating measures or formal risk acceptance are appropriate.

Risk acceptance should be approved by the authorized risk owner and documented with a clear rationale, applicable safeguards, and a review or expiry date where appropriate.

Remediation Closure

A finding or incident should be closed only when the required closure criteria have been met.

These criteria may include completion of the corrective action, verification evidence, updated records, and approval by the designated owner.

If remediation is incomplete or verification fails, the item should remain open, be returned for further action, or be handled according to the organization’s documented exception process.

IT Security Monitoring Metrics and Reporting

IT Security Monitoring metrics help organizations evaluate control coverage, configuration compliance, remediation progress, and the effectiveness of security oversight.

Metrics should provide actionable information for IT Security leadership, IT teams, risk owners, and other relevant stakeholders. They should be interpreted in context rather than used as isolated measures of security performance.

Security Control Coverage Metrics

These metrics measure whether required security controls are deployed across the intended assets and environments.

Examples include:

• Percentage of in-scope endpoints covered by EDR.
• Percentage of critical assets covered by required security controls.
• Percentage of in-scope systems reporting to designated security management platforms.
• Percentage of cloud environments covered by required security monitoring and configuration controls.

Security Configuration and Compliance Metrics

These metrics measure adherence to approved security requirements.

Examples include:

• Percentage of assessed assets compliant with approved security baselines.
• Number of high-risk configuration deviations.
• Percentage of security exceptions reviewed within the required period.
• Number of overdue security configuration corrective actions.

Identity and Access Control Metrics

These metrics measure compliance with identity and access security requirements.

Examples include:

• Percentage of privileged accounts reviewed within the required period.
• Number of inactive or orphaned accounts awaiting remediation.
• Percentage of required access reviews completed on time.
• Number of unresolved high-risk access control findings.
• Percentage of required accounts protected by prescribed authentication controls.

Security Remediation Metrics

These metrics measure the progress and timeliness of corrective actions.

Examples include:

• Percentage of security findings remediated within their assigned SLA.
• Number of overdue high-risk findings.
• Average time taken to remediate findings, segmented by severity.
• Percentage of remediation actions verified successfully.
• Number of findings reopened after unsuccessful remediation.
• Number of unresolved findings with formally approved risk acceptance.

Security Technology Health Metrics

These metrics measure whether security technologies are available and functioning as required.

Examples include:

• Percentage of managed endpoints with healthy and communicating EDR agents.
• Number of critical security technology outages or coverage gaps.
• Percentage of required security policies successfully deployed.
• Number of unresolved security technology configuration issues.

Incident Coordination Metrics

These metrics measure the effectiveness of coordination between the SOC, IT Security, and remediation teams.

Examples include:

• Percentage of security incidents assigned to the appropriate team within the required timeframe.
• Percentage of remediation actions completed within the applicable SLA.
• Number of incidents awaiting remediation beyond their target dates.
• Average time from incident assignment to remediation completion.
• Percentage of incidents with complete remediation and closure evidence.

Metrics such as mean time to detect (MTTD) are primarily associated with detection performance, while mean time to remediate (MTTR) measures remediation performance when clearly defined. Organizations should specify the start and end points used in each calculation to ensure consistent reporting.

Security Monitoring Reports

IT Security Monitoring reports should summarize the state of security controls, significant deficiencies, remediation progress, and risks requiring management attention.

Operational reports may be provided to the teams responsible for remediation, while consolidated reports may be presented to IT Security leadership, the CISO, risk owners, and relevant governance committees.

Reports should identify recurring issues, overdue corrective actions, exceptions, control coverage gaps, and trends that may require changes to security priorities or resource allocation.

Effective reporting should support decisions and corrective action rather than simply count alerts, findings, or completed tickets.

IT Security and Vulnerability Patching

IT Security and Vulnerability Patching involves identifying security vulnerabilities, coordinating remediation activities, implementing corrective measures, and verifying that identified weaknesses have been addressed. It requires collaboration between the Vulnerability Assessment and Penetration Testing (VA/PT) team, IT Security, Governance, Risk and Compliance (GRC), and the IT teams responsible for the affected systems and services.

The VA/PT team assesses vulnerabilities and reports its findings. IT Security coordinates remediation activities across the organization, ensuring that findings are assigned to the appropriate teams and addressed according to their severity and business impact. GRC oversees the formal risk management process, records applicable risks, and follows up on risk treatment activities. The responsible IT teams implement patches and other corrective measures, while designated risk owners make decisions concerning risk acceptance.

This operating model establishes clear responsibilities for vulnerability assessment, remediation coordination, technical implementation, and risk governance.

Understanding Vulnerability Assessment and Remediation

Vulnerability assessment is the process of identifying and evaluating security weaknesses in systems, applications, networks, and infrastructure. These weaknesses may arise from missing security patches, insecure configurations, software vulnerabilities, unsupported components, excessive privileges, or other technical deficiencies.

Vulnerability remediation is the process of addressing identified weaknesses through appropriate corrective measures. Patching is one remediation method, but it is not the only one. Depending on the nature of a vulnerability, remediation may involve software upgrades, configuration changes, disabling vulnerable services, replacing unsupported components, or implementing compensating controls.

Vulnerability management encompasses the broader lifecycle of identifying, assessing, prioritising, tracking, and addressing vulnerabilities. It also involves monitoring remediation progress and validating whether corrective actions have effectively resolved the identified weaknesses.

Vulnerability Assessment

Vulnerability assessment identifies security weaknesses and evaluates their severity, potential impact, and exposure. The assessment may include automated vulnerability scanning, configuration reviews, security testing, and other authorized assessment activities.

Penetration testing complements vulnerability assessment by attempting to validate whether identified weaknesses can be exploited within an authorized testing scope. The findings provide additional information about exploitability and potential consequences.

Vulnerability prioritization

Vulnerabilities must be prioritized according to their severity, exploitability, exposure, business impact, and the criticality of the affected systems. Other relevant considerations include known exploitation, asset importance, regulatory obligations, and available compensating controls.

A vulnerability with a lower technical severity may still require urgent attention if it affects a critical business service or an exposed system. Conversely, remediation priorities should consider the organization’s actual risk context rather than relying exclusively on a technical severity score.

Vulnerability Remediation and Patching

Remediation addresses the identified vulnerability through a suitable corrective measure. Patching involves applying vendor-provided software updates or security fixes to address known vulnerabilities and other software defects.

Where patching is not immediately possible, alternative measures may include disabling an affected service, restricting network access, modifying configurations, upgrading the software, or implementing compensating controls. Such measures should be assessed for effectiveness and tracked until permanent remediation is completed or an authorized risk decision is made.

Vulnerability Remediation and Risk Management

Vulnerability management and risk management are related but distinct processes. Vulnerability management tracks technical findings and their remediation, while risk management evaluates the broader business exposure and governs decisions about risk treatment and acceptance.

Not every vulnerability requires a separate entry in the enterprise risk register. Individual findings may be managed through the vulnerability management process, while significant exposures, unresolved risks, exceptions, and matters requiring formal governance are recorded in the risk register according to organizational policy.

Technical remediation does not automatically close an associated risk record. The risk owner and GRC team must follow the established risk management process to determine whether the risk record requires reassessment, updating, or formal closure.

Team Roles and Responsibilities

Effective vulnerability management requires coordination between teams responsible for technical assessment, remediation, risk governance, and business accountability. Each team contributes to the process according to its defined responsibilities.

Vulnerability Assessment and Penetration Testing (VA/PT) Team

The VA/PT team identifies and assesses vulnerabilities across systems, applications, networks, and infrastructure within the approved assessment scope.

The team documents findings, evaluates their technical severity, provides supporting evidence, and recommends corrective actions. Where assigned, it also performs retesting or validation to determine whether the identified weaknesses have been addressed.

Key responsibilities include:

• Conducting vulnerability assessments and authorized penetration tests.
• Identifying and documenting security weaknesses.
• Evaluating vulnerability severity and technical impact.
• Identifying affected assets and relevant evidence.
• Providing remediation recommendations.
• Communicating findings to IT Security and relevant stakeholders.
• Performing reassessment or retesting where required.
• Reporting findings that remain unresolved after remediation attempts.

The VA/PT team is responsible for assessment and technical validation within its assigned scope. It does not necessarily coordinate every remediation activity or implement patches on the affected systems.

IT Security Team

The IT Security team coordinates vulnerability remediation across the organization. It acts as the coordination point between the VA/PT team, GRC, and the IT teams responsible for affected systems.

After receiving assessment findings, IT Security reviews the results, coordinates prioritization, assigns findings to the appropriate technical teams, and follows up on remediation progress. It also facilitates remediation meetings, monitors overdue findings, and escalates significant exposures.

Key responsibilities include:

• Reviewing and prioritising vulnerability findings with relevant stakeholders.
• Coordinating remediation plans with responsible IT teams.
• Ensuring that findings are assigned to the appropriate system owners or technical teams.
• Establishing remediation timelines in coordination with the relevant stakeholders.
• Monitoring remediation progress and outstanding findings.
• Coordinating retesting and verification activities.
• Following up on remediation delays and implementation constraints.
• Escalating significant vulnerabilities and unresolved exposures.
• Reporting remediation status to IT leadership and relevant stakeholders.

IT Security may directly remediate vulnerabilities affecting security technologies that it owns, such as firewalls, web application firewalls, or endpoint security platforms. However, it does not necessarily perform every vulnerability assessment or patch every system.

Its principal responsibility in this operating model is to coordinate and monitor remediation across the IT environment.

Governance, Risk and Compliance (GRC) Team

The GRC team manages the governance aspects of vulnerability-related risks. It works with IT Security, risk owners, and relevant stakeholders to ensure that significant exposures are assessed, applicable risks are recorded, and risk treatment activities are tracked.

GRC provides oversight of formal risk treatment activities rather than managing the technical implementation of patches.

Key responsibilities include:

• Reviewing vulnerability-related exposures that require formal risk management.
• Coordinating risk assessments with relevant stakeholders.
• Recording applicable risks in the enterprise risk register.
• Tracking risk treatment plans and associated actions.
• Following up on overdue risk treatment activities.
• Recording approved exceptions and risk acceptance decisions.
• Monitoring unresolved risks through the established governance process.
• Escalating outstanding risk treatment actions to the appropriate stakeholders.
• Updating risk records based on reassessment and treatment outcomes.

GRC does not automatically register every vulnerability as a separate enterprise risk. The decision depends on the organization’s risk management methodology, the significance of the exposure, and applicable governance requirements.

Risk acceptance must be approved by the designated risk owner or an appropriately authorized approver. GRC facilitates the governance process but does not independently accept risks on behalf of the business.

IT Infrastructure, Application and Operations Teams

IT Infrastructure, Application and Operations teams are responsible for implementing the technical measures needed to remediate vulnerabilities in the systems and services they manage.

Depending on the affected technology, these teams may apply security patches, upgrade software, change configurations, remove vulnerable components, or implement approved compensating controls.

Key responsibilities include:

• Reviewing assigned vulnerability findings.
• Assessing the impact of proposed remediation on systems and services.
• Preparing remediation plans and implementation schedules.
• Applying security patches and software updates.
• Implementing configuration changes and software upgrades.
• Testing corrective changes before and after implementation, as appropriate.
• Following established change management procedures.
• Providing implementation evidence to IT Security.
• Reporting delays, technical constraints, and unresolved vulnerabilities.
• Implementing approved compensating controls where permanent remediation is not immediately feasible.

Where remediation cannot be completed within the agreed timeframe, the responsible team should document the reason, proposed interim measures, and expected completion date. Any required exception or risk acceptance must follow the organization’s established approval process.

Risk Owners and Management

Risk owners are accountable for the business risks associated with the systems, services, or processes under their responsibility. Management provides oversight when vulnerabilities create significant operational, financial, regulatory, or reputational exposure.

Key responsibilities include:

• Understanding the business impact of unresolved vulnerabilities.
• Supporting remediation prioritization based on business criticality.
• Reviewing significant remediation delays and residual exposures.
• Making or approving risk treatment decisions within their authority.
• Accepting residual risk only where authorized and permitted by organizational policy.
• Ensuring that appropriate resources are available for remediation.
• Reviewing escalated risks and outstanding treatment actions.

Risk acceptance does not remove the underlying vulnerability. It represents an authorized decision to retain the associated residual risk, subject to documented justification, approval, and any applicable review or expiry requirements.

Vulnerability Assessment and Remediation Workflow

The vulnerability assessment and remediation workflow connects the technical findings produced by the VA/PT team with remediation activities coordinated by IT Security, risk governance performed by GRC, and corrective actions implemented by the responsible IT teams.

Vulnerability Assessment by VA/PT

The process begins when the VA/PT team performs an authorized vulnerability assessment or penetration test.

The team identifies weaknesses, documents affected assets, assesses technical severity, and provides evidence and remediation recommendations. The findings are shared with IT Security and the relevant stakeholders through the organization’s established reporting process.

The assessment output should contain sufficient information to support prioritization, assignment, and remediation.

Typical information includes the affected asset, vulnerability description, severity, supporting evidence, potential impact, and recommended corrective action.

Findings Review and Remediation Coordination by IT Security

IT Security reviews the findings received from the VA/PT team and coordinates their assignment to the appropriate IT teams or system owners.

The review considers technical severity, exploitability, business impact, asset criticality, exposure, and applicable remediation requirements. IT Security works with stakeholders to establish priorities and remediation timelines.

Findings that cannot be remediated within the expected timeframe are followed up and escalated according to their significance. IT Security also coordinates with GRC when findings require formal risk assessment, exception handling, or risk treatment tracking.

Risk Assessment and Tracking by GRC

GRC reviews vulnerability-related exposures that require formal risk management.

Where necessary, the relevant risk is assessed and recorded in the risk register. GRC coordinates with IT Security, risk owners, and other stakeholders to establish or track risk treatment actions.

GRC monitors progress against formal risk treatment plans and follows up on overdue actions. Where remediation is delayed or the risk cannot be adequately reduced, the matter may require escalation or an authorized risk acceptance decision.

Technical vulnerability records and enterprise risk records should remain appropriately linked where they relate to the same exposure, while retaining their distinct purposes and closure criteria.

Remediation Planning by IT Teams

The responsible IT teams evaluate the recommended corrective actions and prepare a remediation plan.

The plan identifies the proposed technical changes, implementation responsibilities, expected timelines, testing requirements, and any dependencies or operational constraints.

IT Security coordinates the plan with the relevant stakeholders and monitors progress. Where the proposed remediation cannot be completed within the required timeframe, the responsible team should explain the constraints and propose interim risk-reduction measures.

Vulnerability Remediation and Patching

The responsible IT teams implement the approved corrective measures.

Depending on the vulnerability, remediation may involve applying a security patch, upgrading software, changing configurations, disabling vulnerable services, replacing unsupported components, or implementing compensating controls.

Implementation should follow established change management procedures, including appropriate testing, approvals, scheduling, and rollback planning where required.

After implementation, the responsible team provides evidence of the completed changes to IT Security and the designated validation team.

Remediation Validation and Retesting

After the IT team reports remediation as complete, the VA/PT team or another designated technical validation team verifies whether the vulnerability has been addressed.

Validation may involve rescanning the affected asset, repeating the relevant test, reviewing configuration evidence, or performing another appropriate technical check.

If the vulnerability remains present, the finding should remain open and return to the remediation process. The responsible IT team must investigate the remaining issue and implement additional corrective measures.

Where validation confirms that the vulnerability has been addressed, the finding can proceed towards closure under the organization’s vulnerability management procedures.

Risk Treatment Follow-Up and Closure

IT Security ensures that the technical remediation record is updated and that the required validation evidence is available before the finding is closed.

GRC separately reviews the status of any associated risk treatment activities. Where a risk was recorded in the enterprise risk register, the risk record is updated based on the remediation outcome and the applicable risk management process.

If the vulnerability has been remediated but the associated risk remains, the risk owner and GRC must determine whether further treatment or reassessment is necessary. If residual risk remains and remediation is not feasible or is deferred, any risk acceptance must be formally approved by the authorized risk owner or approver.

This separation ensures that technical findings are closed based on appropriate remediation evidence, while formal risks are managed according to the organization’s governance requirements.

IT Security KPIs

IT Security Key Performance Indicators (KPIs) are measurable indicators used to evaluate the performance of IT security activities against defined objectives, targets, and requirements. They help organizations assess whether security controls, processes, and operational activities are achieving their intended outcomes.

IT Security KPIs provide visibility into areas such as IT governance, risk management, compliance, security monitoring, incident management, and vulnerability remediation. They enable IT Security teams and management to evaluate performance, identify deficiencies, monitor improvements, and make informed decisions about security priorities and resource allocation.

KPIs should be aligned with organizational objectives, security requirements, risk exposure, and operational responsibilities. Their effectiveness depends on using reliable data, clearly defined measurement methods, and meaningful targets.

Purpose of IT Security KPIs

IT Security KPIs help organizations measure and communicate the effectiveness of their IT security activities. They provide a structured basis for evaluating performance, identifying areas requiring improvement, and monitoring progress towards established security objectives.

Performance Measurement

KPIs measure whether IT security activities are achieving their intended outcomes. For example, the percentage of critical vulnerabilities remediated within the required timeframe indicates how effectively the organization addresses high-priority vulnerabilities.

Risk Visibility

KPIs help management understand security weaknesses, outstanding remediation activities, and areas of increased exposure. This information supports risk-based prioritization and decision-making.

Control Effectiveness

KPIs provide evidence of whether security controls are operating as intended. Measurements may include the percentage of systems covered by endpoint protection or the percentage of privileged accounts reviewed within the required period.

Accountability and Oversight

KPIs establish measurable expectations for teams responsible for security activities. They help IT Security, IT Operations, GRC, and management monitor performance within their respective responsibilities.

Continuous Improvement

KPI trends help organizations identify recurring deficiencies, assess the results of corrective actions, and determine whether security performance is improving over time.

IT Security Metrics, KPI and Measurements

KPIs, metrics, and measurements are related concepts, but they serve different purposes.

Metrics

Metrics are quantitative measurements used to monitor activities, processes, systems, or outcomes. Examples include the number of open vulnerabilities, the number of security incidents detected, and the number of systems covered by security monitoring.

Key Performance Indicators (KPIs)

KPIs are selected metrics that indicate progress towards important security objectives or performance expectations. Examples include the percentage of critical vulnerabilities remediated within the required timeframe and the percentage of security incidents handled within defined service-level targets.

Measurements

Measurements are the observed values collected for a metric or KPI during a defined period. For example, if 90 out of 100 critical vulnerabilities are remediated within the required timeframe, the measured compliance rate is 90%.

Not every security metric is a KPI. A metric becomes a KPI when it is linked to a defined objective and used to evaluate performance against an agreed target or expectation.

IT Security KPI Framework

An IT Security KPI framework establishes how security performance indicators are selected, defined, measured, monitored, and reported. It helps ensure that KPIs are consistent, meaningful, and aligned with organizational requirements.

KPI Definition and Measurement

Each KPI should have a clearly defined purpose, calculation method, data source, owner, measurement period, and reporting frequency. These elements ensure that the KPI can be measured consistently and interpreted correctly.

A KPI definition should specify:

• KPI Name: The name of the indicator.
• Purpose: The security objective or performance expectation being measured.
• Calculation: The formula used to calculate the result.
• Data Source: The system, report, or record from which the data is obtained.
• Target: The expected level of performance.
• Owner: The individual or team responsible for monitoring and improving performance.
• Measurement Period: The period over which the KPI is evaluated.
• Reporting Frequency: How often the results are reported.

For example, a vulnerability remediation KPI may measure the percentage of critical vulnerabilities remediated within the organization’s defined remediation timeframe.

Example Calculation

Percentage of Critical Vulnerabilities Remediated Within the Required Timeframe:

Percentage = (Number of critical vulnerabilities remediated within the required timeframe ÷ Total critical vulnerabilities due for remediation during the measurement period) × 100

If 90 out of 100 critical vulnerabilities due for remediation during the period are remediated within the required timeframe, the KPI result is 90%.

The organization should define how reopened findings, accepted risks, overdue findings, and vulnerabilities discovered during the measurement period are handled to ensure consistent reporting.

KPI Targets and Thresholds

KPI targets establish the expected level of performance for a security activity. Thresholds indicate when performance requires attention, investigation, or escalation.

Targets should reflect business requirements, risk appetite, regulatory obligations, contractual commitments, and operational capabilities. They should not be selected arbitrarily or assumed to be universal across all organizations.

For example, an organization may establish a target for remediating critical vulnerabilities within a specified number of days. A threshold may trigger escalation when remediation performance falls below the approved target.

KPI results can be classified using performance bands such as:

• Target Achieved: Performance meets or exceeds the defined target.
• Attention Required: Performance is approaching a threshold or showing signs of deterioration.
• Target Not Achieved: Performance falls below the defined target and requires investigation or corrective action.

The organization should document the criteria for each performance band and define the actions required when thresholds are breached.

IT Security KPI Types

IT Security KPIs can be grouped according to the security functions and management activities they measure. The following types cover key areas of IT Security governance, control implementation, operational performance, and risk management.

IT Governance KPIs

IT Governance KPIs measure the performance of governance activities, including policy implementation, accountability, oversight, and management review.

Examples include:

• Percentage of IT security policies reviewed within the required period.
• Percentage of assigned security governance actions completed by their due dates.
• Percentage of scheduled IT security governance reviews completed.
• Percentage of security governance decisions implemented within agreed timelines.

These KPIs help management evaluate whether security governance activities are performed according to established requirements.

IT Risk Management KPIs

IT Risk Management KPIs measure the performance of activities used to identify, assess, treat, and monitor IT security risks.

Examples include:

• Percentage of identified high-risk issues with approved treatment plans.
• Percentage of risk treatment actions completed within agreed timelines.
• Number of overdue high-risk treatment actions.
• Percentage of risk reviews completed according to the defined schedule.

These KPIs help management assess whether identified risks are being addressed and whether risk treatment activities are progressing as expected.

IT Compliance KPIs

IT Compliance KPIs measure adherence to applicable policies, standards, regulatory requirements, and contractual obligations.

Examples include:

• Percentage of applicable compliance requirements assessed within the reporting period.
• Percentage of identified compliance deficiencies remediated by their due dates.
• Number of overdue compliance actions.
• Percentage of scheduled compliance reviews completed.

These KPIs help organizations monitor compliance performance and identify outstanding deficiencies requiring corrective action.

IT Control Effectiveness KPIs

IT Control Effectiveness KPIs measure whether selected IT security controls are implemented, operating, and achieving their intended objectives.

Examples include:

• Percentage of in-scope systems covered by endpoint protection.
• Percentage of sampled systems meeting defined security configuration requirements.
• Percentage of scheduled access reviews completed.
• Percentage of tested security controls operating effectively.

These KPIs provide evidence of control coverage and performance. However, control coverage alone does not establish effectiveness; testing and appropriate supporting evidence may also be required.

IT Security Monitoring KPIs

IT Security Monitoring KPIs measure the performance and coverage of security monitoring activities across systems, infrastructure, and services.

Examples include:

• Percentage of in-scope critical systems integrated with security monitoring.
• Percentage of monitored systems forwarding the required security logs.
• Percentage of critical monitoring alerts processed within defined service-level targets.
• Number of critical systems with monitoring coverage gaps.

These KPIs help assess whether relevant systems are covered by monitoring and whether monitoring activities meet defined operational expectations.

Security Incident Management KPIs

Security Incident Management KPIs measure the organization’s performance in detecting, investigating, containing, resolving, and closing security incidents.

Examples include:

• Mean Time to Detect (MTTD) security incidents.
• Mean Time to Contain security incidents.
• Mean Time to Resolve security incidents.
• Percentage of security incidents handled within defined service-level targets.
• Percentage of post-incident corrective actions completed by their due dates.

Definitions should specify the start and end points for each time-based KPI. For example, time to detect may be measured from the earliest established occurrence of an incident to its detection, while time to contain may be measured from detection to the implementation of effective containment.

The accuracy of these KPIs depends on reliable incident records and consistent timestamp definitions.

Vulnerability Assessment and Remediation KPIs

Vulnerability Assessment and Remediation KPIs measure how effectively vulnerabilities are assessed, prioritized, remediated, and validated.

Examples include:

• Percentage of critical vulnerabilities remediated within the required timeframe.
• Percentage of high-severity vulnerabilities remediated within the required timeframe.
• Number of overdue critical vulnerabilities.
• Average time to remediate vulnerabilities by severity.
• Percentage of remediated vulnerabilities successfully validated.
• Percentage of vulnerability findings with assigned remediation owners.

These KPIs help IT Security monitor remediation performance and identify teams, systems, or processes requiring additional attention.

The measurement criteria should distinguish between a vulnerability reported as remediated and one that has been technically validated.

Identity and Access Control KPIs

Identity and Access Control KPIs measure the implementation and operation of controls that govern user identities, access rights, authentication, and privileged access.

Examples include:

• Percentage of scheduled user access reviews completed within the required timeframe.
• Percentage of privileged accounts covered by the required security controls.
• Percentage of terminated-user accounts disabled within the required timeframe.
• Percentage of in-scope users covered by multifactor authentication.
• Number of overdue access review findings.

These KPIs help assess access control coverage, review completion, and the timely removal of unnecessary access.

The organization should define the population of users, accounts, applications, and systems included in each calculation.

IT Security KPI Measurement and Reporting

KPI measurement and reporting transform security data into information that supports operational decisions, management oversight, and governance.

KPI Performance Evaluation

KPI performance evaluation involves comparing measured results against established targets and reviewing trends over time.

A single KPI value may not provide sufficient information to understand the underlying performance. Results should be interpreted alongside the relevant business context, risk exposure, measurement period, and supporting operational data.

For example, a reduction in open vulnerabilities may indicate improved remediation performance. However, the result could also reflect a reduction in assessment coverage or fewer vulnerabilities being identified. The organization should consider these factors before drawing conclusions.

Performance evaluation should include:

• Comparison of actual results against defined targets.
• Identification of adverse trends and recurring deficiencies.
• Investigation of threshold breaches.
• Assessment of corrective actions and their effectiveness.
• Review of changes in risk exposure and operational requirements.

Where performance falls below an established target, the responsible team should investigate the cause, define corrective actions, assign ownership, and monitor progress.

IT Security KPI Reporting

IT Security KPI reporting communicates security performance to stakeholders according to their responsibilities and information needs.

Operational teams generally require detailed information about individual findings, outstanding actions, and service-level performance. IT leadership and the CISO require a consolidated view of security performance, significant deficiencies, risk exposure, and areas requiring management intervention. GRC uses relevant KPI information to support risk oversight, compliance monitoring, and governance reporting.

An IT Security KPI report may include:

• KPI name and purpose.
• Reporting period and measured result.
• Target and performance status.
• Comparison with previous reporting periods.
• Significant deviations or threshold breaches.
• Relevant risks and operational impacts.
• Corrective actions, responsible owners, and target dates.

Dashboards can help present KPI results through summary indicators, trends, and performance comparisons. However, visualization should support accurate interpretation rather than replace the underlying definitions and supporting evidence.

KPI reports should be consistent, traceable to reliable data sources, and tailored to the audience. They should enable stakeholders to understand what the results mean, which areas require attention, and what actions are necessary.

Ultimately, IT Security KPIs provide a structured way to evaluate security performance and communicate whether security activities are achieving their intended outcomes. When aligned with business objectives, supported by reliable measurement methods, and reviewed regularly, KPIs help organizations improve security oversight and make informed decisions.

References

Online Sources

NIST – Cybersecurity Framework (CSF) 2.0
Provides guidance for managing cybersecurity risks, establishing governance, and defining cybersecurity outcomes.

NIST – Computer Security Resource Center (CSRC)
Provides cybersecurity publications, standards, guidelines, and technical resources covering security controls, risk management, incident handling, and security assessments.

NIST – Security and Privacy Controls for Information Systems and Organizations
Provides a catalog of security and privacy controls for information systems and organizations.

NIST – Computer Security Incident Handling Guide
Provides guidance for preparing for, detecting, analyzing, responding to, and recovering from computer security incidents.

NIST – Technical Guide to Information Security Testing and Assessment
Provides guidance on planning and conducting technical security assessments, analyzing findings, and developing mitigation strategies.

ISACA – COBIT
Provides a framework for the governance and management of enterprise information and technology, including governance objectives, risk management, controls, and performance measurement.

PeopleCert – ITIL
Provides guidance on IT service management, including incident management, change management, service operations, and continual improvement.

ISO – ISO/IEC 27001 — Information Security Management Systems
Specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system.

CIS – CIS Critical Security Controls
Provides prioritized safeguards to help organizations strengthen their security posture, manage vulnerabilities, monitor security events, and respond to incidents.