Skip to main content

Operating the ISMS at Scale: Asset Management, Change Control, Supplier Risk, and Incident Response in Motion

"In theory there is no difference between theory and practice. In practice there is."

  • Yogi Berra

Introduction: The Gap Between Design and Operation​

Every ISMS looks good on paper. Policies are coherent. The risk register is thoughtful. The SoA is complete. The documentation architecture is sound. And then the organization goes live - systems change, suppliers are onboarded, incidents occur, employees join and leave, new regulations emerge - and the ISMS either proves itself operational or reveals itself as a set of documents that describes an organization that exists only in the policy library.

The operational ISMS is the one that works during the messy, continuous reality of organizational life. It is the one where asset management keeps pace with cloud sprawl and shadow IT. Where the change control process is used by engineers because it is useful, not bypassed because it is burdensome. Where supplier risk management is continuous, not a checkbox at contract signing. Where the incident response procedure is executed from memory under pressure, not discovered in a SharePoint folder an hour after the attacker has been inside the network.

This chapter covers the four domains where the gap between ISMS design and ISMS operation is widest, most consequential, and most commonly exploited - by auditors, by threat actors, and by the ordinary entropy of organizational change.

Part 1 - Asset Management in Motion​

1.1 Why Asset Management Is Never Finished​

The asset inventory established during ISMS setup was accurate at a point in time. From the moment it was completed, it began to drift from reality. Understanding why this drift is inevitable - and what operational disciplines manage it - is the starting point for treating asset management as a continuous process rather than a periodic exercise.

Technology deployment velocity. In organizations with active development programs, cloud-native infrastructure, or distributed IT procurement, new assets come into existence faster than manual inventory processes can capture them. A developer who spins up an AWS EC2 instance for a project, a marketing team that subscribes to a new SaaS analytics platform, an operations team that deploys an IoT sensor network - each of these creates new information assets that exist in the environment before they appear in any register.

The shadow IT problem at scale. Shadow IT is not a pathology of immature organizations. It is a predictable consequence of the gap between user needs and IT delivery capacity. When employees find that sanctioned tools are inadequate and the approval process takes months, they use alternatives.

Asset state changes. Assets in the inventory may change in ways that alter their risk profile without being removed or replaced - a server migrated from on-premises to cloud, a database that begins storing a new category of data, a system downgraded from critical to decommission-pending.

Third-party asset dynamics. Assets held by third parties - cloud providers, managed service providers, SaaS platforms - change continuously as those providers update their infrastructure, policies, and service configurations.

1.2 Continuous Asset Discovery: The Technical Dimension​

Network discovery scanning. Regular automated scans of the network environment identify connected devices, running services, and open ports. Tools such as Qualys, Tenable, or Rapid7 provide a continuously updated picture of what is on the network.

Cloud asset management. Cloud service providers offer native inventory services - AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory - that enumerate all resources in the cloud environment. Multi-cloud environments require either each provider's native tools or a third-party CSPM platform.

SaaS discovery. CASB tools and SaaS management platforms analyze network traffic, OAuth grants, and identity provider logs to identify all SaaS applications in use - authorized and unauthorized.

Data discovery and classification. Data discovery tools scan storage systems, file shares, databases, and cloud storage to identify where sensitive data resides - including locations that were not expected or approved.

1.3 The Asset Lifecycle Process​

Acquisition and onboarding: New assets should enter the environment through a process that includes security assessment before deployment. The asset register entry should be created at this stage, not retroactively.

Classification and ownership assignment: Every asset should be classified according to the information classification scheme and assigned an owner who is accountable for its security.

Operational monitoring: Once in the environment, assets should be monitored for security compliance - configuration drift, vulnerability exposure, unauthorized changes, unusual activity.

Change management: Changes to assets should flow through the change management process. The asset register should be updated to reflect changes that affect the asset's classification, ownership, or risk profile.

Decommissioning and disposal: When assets are retired, the decommissioning process must address information security - secure data deletion, return of licenses, revocation of access permissions, update of the asset register, and for physical assets, secure disposal or reuse (Annex A 7.14).

1.4 The Information Classification Lifecycle​

Information classification is not a one-time labelling exercise. Information changes in sensitivity over time.

Classification drift downward: Information that was highly sensitive at creation - strategic plans, financial projections, product roadmaps - may become public or lose its sensitivity as time passes.

Classification drift upward: Information that was created as routine may become sensitive as its context changes.

Classification review triggers: Classifications should be reviewed when information is shared beyond its original audience, when the regulatory or legal status changes, or when the time sensitivity has expired.

Part 2 - Change Control as a Security Control​

2.1 Why Change Is the Most Dangerous Routine Activity​

The majority of significant security incidents that are not caused by external attack are caused by change - a configuration change that inadvertently opens a firewall port, a software update that removes a security control, a network topology change that eliminates a segmentation boundary.

Change is dangerous because it introduces uncertainty. A system whose configuration has been stable for six months has a known, assessed security posture. The moment a change is made, the security posture is uncertain until the change has been verified.

The ISO 27001 change management control (Annex A 8.32) requires that changes to information processing facilities and systems follow a documented process - to ensure that security implications are assessed before changes are made, that changes are tested before deployment to production, and that changes can be reversed if they introduce unexpected security consequences.

2.2 The Security-Integrated Change Management Process​

Request and classification: Every change should be formally requested. Changes should be classified by risk level - standard changes (low-risk, pre-approved types), normal changes (requiring assessment and approval), and emergency changes (bypassing normal approval for urgent operational reasons, with retrospective review required).

Security impact assessment: Before a change is approved, its security implications should be assessed - what controls does this change affect? Does it change the attack surface? Does it affect data flows or data classification?

Testing: Changes should be tested in a non-production environment before deployment to production. Security testing - verifying that the change does not introduce vulnerabilities or remove security controls - should be included in testing criteria.

Deployment and verification: After deployment, the change should be verified to have been implemented as intended. Security controls affected by the change should be verified to be operational.

Post-change review and record: The change record should be updated with the outcome. For emergency changes, the formal change record should be completed retrospectively and reviewed at the next change management forum.

2.3 Emergency Changes: The Security Risk in the Exception Process​

Emergency changes deserve specific attention because they are simultaneously the changes most likely to introduce security vulnerabilities and the changes least likely to go through adequate security review.

Minimum approval level: Even emergency changes should require approval by someone with the authority to accept the associated risk.

Security awareness: The person implementing the emergency change should be aware of the security implications of what they are doing.

Mandatory retrospective review: Every emergency change should be subject to mandatory retrospective review within a defined timeframe - typically 5 business days.

Logging and audit trail: Emergency changes should be logged as carefully as planned changes.

2.4 Configuration Management and Change Control​

Configuration management - maintaining documented, verified configurations for all systems and ensuring that deviations from those configurations are detected and addressed - is the complementary discipline to change management. Where change management controls intended changes, configuration management detects unintended changes.

An operational configuration management program includes:

Defined security baselines. For each category of system, a documented security baseline defines the required configuration - which services are enabled, which ports are open, which security settings are active. CIS Benchmarks are common sources for baseline configurations.

Automated compliance scanning. Regular automated comparison of actual system configurations against the approved baseline, with alerting for deviations. CSPM tools for cloud environments; Chef InSpec, Puppet, or commercial equivalents for on-premises infrastructure.

Change-triggered configuration verification. After any change that affects system configuration, a verification that the resulting configuration remains compliant with the security baseline.

Configuration drift response. A defined process for responding when configuration drift is detected - investigating why the drift occurred, restoring the compliant configuration, and addressing the root cause.

Part 3 - Supplier Risk Management as a Continuous Discipline​

3.1 The Supplier Risk Lifecycle​

The traditional approach - assess the supplier at procurement, include security requirements in the contract, file the contract, and address supplier security again only if an incident occurs - was inadequate in 2013. By 2024, it is professionally indefensible. The supply chain attack landscape has fundamentally changed the calculus of third-party risk.

The continuous approach requires a supplier risk management lifecycle that operates throughout the relationship:

Onboarding assessment: Before a new supplier relationship commences, the supplier is assessed against security requirements appropriate to the risk they represent.

Contractual requirements: Security requirements are embedded in supplier contracts with specificity proportionate to the supplier's risk profile. Key contract elements for security:

  • Minimum security control requirements, with reference to a specific standard or framework
  • Right-to-audit provisions
  • Sub-processor notification and approval requirements
  • Incident notification requirements
  • Data return and deletion requirements at contract termination
  • Business continuity requirements relevant to the services provided

Continuous monitoring: Threat intelligence monitoring for incidents at the supplier, service-level and security metric reporting where contractually required, external security ratings services, direct engagement with strategic suppliers.

Periodic review: At defined intervals - at least annually, more frequently for high-risk suppliers - a formal review of the supplier's security posture, compliance with contractual requirements, and any changes to their risk profile.

Exit and offboarding: Data return and verified deletion, access revocation, credential rotation, and review of whether any residual risk remains.

3.2 The Supplier Tiering Framework​

Tier 1 - Critical Suppliers: Definition: Suppliers with privileged access to production systems, suppliers who process significant volumes of sensitive personal data, suppliers whose failure or compromise would directly impact operations. Management requirements: Full security assessment at onboarding; contractual security requirements with audit rights; quarterly or semi-annual security reviews; immediate notification of material changes.

Tier 2 - High-Risk Suppliers: Definition: Suppliers with access to organizational systems or data without privileged access; suppliers who provide services with a significant dependency relationship. Management requirements: Security questionnaire assessment at onboarding; standard contractual security clauses; annual security review; monitoring of public breach intelligence.

Tier 3 - Standard Suppliers: Definition: Suppliers who provide goods or services without access to organizational information systems or sensitive data. Management requirements: Standard contractual terms; no specific security assessment required; review triggered only by significant change.

3.3 The Critical Supplier Review: What It Must Cover​

A substantive critical supplier review covers:

Access profile review: What access does this supplier currently have? Has their access profile changed since the last review?

Incident history review: Has the supplier experienced any security incidents since the last review, regardless of whether those incidents affected the organization directly?

Subprocessor changes: Has the supplier engaged any new subprocessors since the last review?

Certification and compliance status: Is the supplier's security certification current?

Contractual compliance review: Is the supplier meeting the security requirements set out in the contract?

Service change assessment: Has the supplier made material changes to how they deliver services that have security implications?

3.4 Fourth-Party Risk: The Supplier's Suppliers​

The SolarWinds attack demonstrated that third-party risk management programs that focus exclusively on direct suppliers are structurally incomplete. Fourth-party risk - the risk arising from the suppliers and sub-processors engaged by direct suppliers - is genuinely difficult to manage.

Practical approaches:

Contractual flowdown: Require in supplier contracts that the supplier applies equivalent security requirements to their subprocessors.

Material subprocessor notification: Require suppliers to identify their material subprocessors and notify of any changes.

Software composition analysis: Automated tools that analyze the software components, libraries, and build tools used by software suppliers can identify dependency risks.

Threat intelligence monitoring: Monitor threat intelligence sources for incidents affecting major software vendors and platforms commonly used across the supplier base.

Part 4 - Incident Response in Motion​

4.1 The Incident Response Capability Model​

An incident response capability is not a document. It is a combination of prepared people, tested processes, appropriate technology, and practiced judgment. Most organizations have the document. Fewer have the capability. The preparation gap closes through practice, not through documentation.

4.2 Incident Detection: The First and Hardest Step​

The average dwell time - the period between initial compromise and detection - for sophisticated attacks remains measured in weeks to months despite significant investment in detection capabilities.

Alert fatigue is the primary detection failure mode. Security monitoring tools generate more alerts than the security team can investigate. Detection capability investment should focus on alert quality (reducing false positives through tuning) as much as alert quantity.

The unknown threat problem. Signature-based detection does not detect novel attacks or living-off-the-land techniques. Behavioral detection is more effective against sophisticated attackers but generates more false positives.

Visibility gaps. Detection capabilities are limited by visibility. Most organizations have better visibility into on-premises infrastructure than cloud environments, better visibility into servers than endpoints.

The insider threat detection challenge. Insiders have legitimate access; their behavior is expected and therefore less likely to trigger anomaly detection. UEBA tools are the most effective technical mechanism for insider threat detection.

4.3 The First 24 Hours: A Practitioner's Guide​

Hour 0–1: Detection and initial triage

Triage questions:

  • Is there credible evidence of compromise, or is this a false positive?
  • If compromise, what is the scope - which systems or data appear to be involved?
  • Is the attack ongoing, or has it concluded?
  • Is there an immediate threat to critical operations, safety, or regulatory obligations?

Hour 1–4: Containment and escalation

Contain the threat: Isolation options range from network isolation and account lockout to blocking specific traffic or revoking specific credentials. The choice must balance speed against forensic preservation and business continuity.

Preserve evidence: Before making changes to affected systems, capture forensic evidence - system images, memory captures, log extracts, network traffic captures.

Escalate appropriately: Internal escalation to the CISO, executive leadership, legal and compliance, and affected business units should be guided by pre-defined escalation criteria.

Hour 4–12: Investigation and communication

Scope determination: What systems were accessed? What data may have been exposed? This is the foundation for all subsequent decisions.

Regulatory notification clock: If the incident involves personal data, the GDPR 72-hour notification clock begins running from when the organization becomes aware that a personal data breach has occurred - not from when investigation is complete.

Communication management: Who will communicate with regulators, customers, law enforcement, and the media, and what will they say?

Hour 12–24: Remediation and recovery

Eradication: Remove the attacker's presence from the environment - malware, backdoors, unauthorized accounts, persistence mechanisms. Partial eradication that leaves the attacker with a path back results in re-compromise.

Recovery: Restore affected systems to operational status, verifying security controls before reconnecting to production networks.

Post-incident documentation: Create contemporaneous records of everything done, observed, and decided during the response.

4.4 Regulatory Notification: The Compliance Dimension​

GDPR breach notification:

  • To supervisory authority: Within 72 hours of becoming aware of a personal data breach.
  • To affected individuals: Without undue delay where the breach is likely to result in a high risk to individuals' rights and freedoms.

Practical challenge: The 72-hour window from "becoming aware" to regulatory notification is extremely short for a complex incident. The correct approach is to notify early with the information available and provide updates as additional information becomes available.

NIS2 incident notification (for essential and important entities):

  • Initial notification: Within 24 hours - preliminary notice indicating whether the incident is suspected to be the result of unlawful or malicious acts.
  • Incident notification: Within 72 hours of awareness.
  • Final report: Within one month.

DORA incident classification and reporting (for financial entities): Initial notification within 4 hours of classification as major, intermediate report within 72 hours, and final report within one month.

4.5 The Post-Incident Review: Converting Incidents Into Improvements​

An effective post-incident review answers five questions:

What happened? A factual reconstruction of the incident timeline - accurately, not sanitized.

Why did it happen? Root cause analysis - not just the proximate cause but the underlying organizational and process factors that enabled it.

How was the response? An honest assessment of response effectiveness - what went well, what was slow, what decisions were wrong.

What risks did this incident reveal? Was this a risk that had been identified and accepted? A risk that had been identified but whose likelihood or impact was underestimated? A risk not identified at all?

What will change? Specific, owned, time-bound corrective actions that address the root causes identified.

Part 5 - The Operational ISMS Calendar​

5.1 The Rhythm of Operational Security Management​

An ISMS that operates well has a rhythm - a defined schedule of recurring activities that keeps the management system current, the evidence records populated, and the organization's security posture continuously assessed and adjusted.

5.2 Weekly Operational Activities​

Security monitoring review: Review SIEM alerts, threat intelligence feeds, and anomalous event reports.

Vulnerability scan review: Review automated vulnerability scan results for critical and high-severity findings.

Access provisioning and revocation: Process access requests and revocations. Verify that all joiners and leavers have been correctly handled.

Change management review: Review change requests for security impact. Confirm that emergency changes have been retrospectively documented.

5.3 Monthly Operational Activities​

Security metrics report: Compile and distribute the monthly security metrics report to senior management. Core metrics: MTTD, MTTR, vulnerability management statistics, access review completion rate, training completion rate.

Supplier security monitoring: Review threat intelligence and public breach sources for incidents at key suppliers.

Risk register update: Review the risk register for any changes - new assets, organizational changes, incidents, or threat intelligence updates.

Patch compliance review: Review patch compliance status across all in-scope systems. Identify and escalate systems outside the patching SLA.

5.4 Quarterly Operational Activities​

Management security briefing: Present a quarterly security briefing to the executive team or board committee responsible for ISMS oversight.

Access review cycle: Conduct a formal review of access rights for high-value systems and sensitive data.

Phishing simulation: Conduct a phishing simulation exercise against a representative sample of staff.

Supplier review - Tier 1: Conduct formal quarterly security reviews for Tier 1 (critical) suppliers.

Business continuity test: Conduct at least one business continuity or disaster recovery test per quarter, including actual restoration of systems from backup.

5.5 Annual Operational Activities​

Full risk assessment refresh: Comprehensive review of the risk register - updating asset valuations, refreshing threat assessments, reassessing control effectiveness.

Internal audit program: Execute the annual internal audit program, covering all aspects of the ISMS.

Management review: Conduct the formal annual management review covering all required inputs under Clause 9.3.

Policy review cycle: Review all ISMS policies against current regulatory requirements and operational experience.

SoA review: Review the Statement of Applicability for currency.

Supplier review - full portfolio: Annual review of the complete supplier portfolio.

Penetration test: Annual penetration test of the in-scope environment.

Awareness training refresh: Update annual security awareness training content to reflect current threat landscape and lessons learned.

Part 6 - Scaling the ISMS: Size, Complexity, and Resource Constraints​

6.1 The Small Organization ISMS​

For organizations with limited security resources, the operational ISMS presents specific challenges. The standard does not reduce its requirements based on organizational size, but it does allow proportionality in how those requirements are met.

Concentration risk in security roles. In small organizations, one person may be responsible for most ISMS activities. This creates concentration risk (when that person is unavailable, ISMS activities stop) and independence risk (the same person who implements controls cannot independently audit them).

Practical mitigations:

  • Document all ISMS processes at sufficient granularity that a covering person can perform them
  • Use external auditors for the internal audit function to achieve independence
  • Automate what can be automated - monitoring, vulnerability scanning, configuration compliance

Resource-prioritized control implementation. The risk assessment should drive explicit prioritization - the controls that address the highest risks receive the most investment.

6.2 The Enterprise ISMS: Managing Complexity at Scale​

The federated ISMS model. Many large organizations operate a federated ISMS - a central ISMS framework that defines common standards and minimum requirements, with subsidiary or business-unit ISMSs that implement the central requirements in their specific context.

Cross-functional governance. An enterprise ISMS requires governance structures that bring together IT, security, legal, compliance, HR, procurement, and operations in a way that produces coherent security decisions rather than a collection of independent programs.

Metrics aggregation. Enterprise security metrics reporting requires aggregation of security data from across the organization - centralized security monitoring, consolidated vulnerability management, aggregated training completion data.

Summary: What Chapter 6 Has Established​

The operational ISMS is where security policy meets organizational reality.

Asset management is never finished. Continuous discovery mechanisms, lifecycle management disciplines, and classification maintenance are the operational practices that keep the asset register current and the risk assessment relevant.

Change management is one of the most underappreciated security controls. Changes introduce uncertainty into the security posture; change control manages that uncertainty through assessment, testing, and verification.

Supplier risk management has been permanently transformed by the supply chain attack landscape. Continuous monitoring, tiered risk management, and contractual mechanisms for visibility into fourth-party relationships are the operational requirements of a mature supplier risk program.

Incident response is a capability, not a document. The gap between having an incident response plan and being able to execute it effectively under pressure is closed only through practice.

The operational calendar - the rhythm of weekly, monthly, quarterly, and annual activities - is the practical mechanism that turns the ISMS from a certification artifact into a living security management system.

Next: Chapter 7 - Measuring What Matters: KPIs, Internal Audit Programs, Management Review, and Continual Improvement Loops

© ISO 27001 Wiki - For CISOs, Security Analysts, and GRC Professionals