Category: #CCM

Posted on

SOC 2 Control Ownership in 2026: A Practical List When You Have No CISO

An access review can be scheduled, a logging platform can be running and a vendor questionnaire can be filed. The gap appears when nobody is responsible for checking whether all relevant accounts, systems and suppliers were actually covered.

That is why a SOC 2 control list needs more than control names. In an organization without a CISO, engineering, IT, people operations, procurement and leadership may all run parts of the programme. Each control needs an operational owner, a clear escalation path and evidence that matches the period and scope of the SOC 2 examination.

This guide offers a practical ownership model for 2026. It keeps the focus on the Trust Services Criteria, representative control domains, a usable SOC 2 RACI, and the work needed to close gaps before they become audit findings.

What belongs on a SOC 2 control list?

SOC 2 is an attestation report on controls at a service organization relevant to one or more of five Trust Services Criteria categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security provides the common criteria; the other categories are selected based on the service, commitments and report scope.

There is no universal AICPA checklist of prescribed tools, owners and evidence files for every company. Management describes the system and designs controls to meet the applicable criteria. The independent CPA firm examines that description and the controls within the agreed scope. A template can help organize work, but it must reflect what the company actually operates.

For each control, record:

  • The objective and the system or population in scope
  • Who performs the control and who is answerable for the outcome
  • How often the control runs or is reviewed
  • Where authoritative evidence is generated and retained
  • How a failed check is escalated, remediated and verified

For a Type 2 report, the operating trail matters across the examination period. A control that looks correct on the last day may still have gaps earlier in the period. Agree on the report scope and evidence expectations with the CPA firm rather than assuming one generic frequency applies to every control.

Who owns SOC 2 controls without a CISO?

Management remains responsible for its system and control environment even when no executive has a CISO title. A founder, COO or technology leader may sponsor the programme. Day-to-day control ownership should sit with people who can direct the underlying process and resolve a failure.

The programme coordinator can track deadlines and auditor requests, but should not silently own every technical, HR and supplier control. Separate control operation from programme coordination.

The following is an illustrative SOC 2 control list, not a list required by AICPA. Adjust it for your services, selected criteria and team structure.

Control areaLikely operational ownerPartnersEvidence and useful outcome check
Identity and accessIT or identity leadHR, system ownersJoiner and leaver records, access reviews; check that all in-scope accounts were included
Production changesEngineering or platform leadProduct, securityPull requests, approvals, deployment records; reconcile changes with production releases
Cloud configuration and monitoringPlatform leadService owners, incident respondersBaselines, alert records, log-feed health; check critical assets and response ownership
Incident responseIncident lead or operations leaderLegal, support, leadershipEscalation record, exercise or incident timeline, follow-up actions; verify closure
Supplier oversightProcurement or vendor ownerLegal, engineering, data ownersDue diligence, contracts and review dates; check critical providers and open findings
Workforce securityPeople operationsIT, managersTraining, onboarding and departure records; reconcile departures with access removal
Data protection and recoveryService or data ownerPlatform, privacy teamEncryption settings, backup and restore results; check sensitive data and critical services

The specific owner may differ. For example, engineering could own application access while IT owns the central identity platform. Avoid treating the department names in a sample table as an audit requirement.

Make ownership specific enough to act

“IT owns access” is useful at a planning level. It is insufficient when a quarterly review is due and nobody knows who will generate the account list, who will approve each exception or who will revoke access.

For each recurring control, identify a named coordinator or role with an assigned incumbent, the reviewers who make decisions and the person authorized to resolve exceptions. Define a backup when the primary person is unavailable. Record the evidence source before the first review, not during the auditor’s sample request.

Consider a departure process. People operations records the departure date, IT disables central accounts, application owners remove local access and a manager checks that the work is complete. The programme owner tracks missed steps. A strong control record ties those events to the same person and date range, and flags any application that was omitted.

Review assignments after a new SaaS deployment, reorganization or acquisition. An old control map may no longer match the systems and reporting lines in use.

Use a SOC 2 RACI as a working map

A RACI can distinguish who is Responsible for performing a task, Accountable for its outcome, Consulted for expertise and Informed about its status. It is a management tool, not a SOC 2 requirement by name. Use it where multiple teams touch the same control.

For example, for employee offboarding:

ActivityResponsibleAccountableConsultedInformed
Record departure and trigger workflowPeople operationsPeople operations leadEmployee’s managerIT
Remove central and application accessIT and application ownersIT leadPeople operationsManager
Investigate missed access and confirm closureRelevant system ownerIT leadRisk or compliance coordinatorExecutive sponsor

The exact assignments depend on authority in your organization. The point is to avoid a control falling between two teams because each believes the other will complete it. An auditor assesses the control against the applicable criteria and the organization’s description; a perfect-looking RACI does not replace evidence of execution.

What evidence proves a control operated?

Start from the system that performs the activity. An access review needs the source population, reviewer, review date, decisions and evidence of action on exceptions. A change control needs the proposed change, approval, release record and any required post-deployment check. An incident control needs an escalation and response trail, not merely an approved response plan.

The evidence should answer four questions: What was in scope? When did the activity occur? Who made the decision? What happened to any exception?

Screenshots without timestamps or asset context make those answers difficult. A dashboard showing that a tool was installed does not necessarily prove that every relevant asset was protected.

For a SOC 2 Type 2 examination, establish a cadence that can operate throughout the reporting period. Track missed reviews and failed checks when they occur. Corrective action should show an owner, a due date, the fix and a recheck. Do not quietly replace missing historical evidence with a new screenshot at the end of the period.

A practical example: privileged access across a growing service

Suppose a SaaS company has moved several production workloads to a new cloud account. Its SOC 2 control list says privileged access is reviewed, and the IT lead has signed the latest review. Yet the cloud administrator roles created during the migration are absent from the identity export used for that review.

The review happened, but its population was incomplete. The service owner identifies the new roles, the identity owner compares them with approved access, and the platform team closes any excessive permissions. The team then updates the review source and documents a check that the next review includes all production accounts.

This example illustrates why SOC 2 control ownership should connect the control, the systems it covers and the people who can fix a gap. The decision is more useful than a simple “review complete” status because it identifies what was missed and how the outcome was validated.

How to assign SOC 2 ownership in five steps

  1. Confirm report scope. List the service, systems, locations, subservice relationships and Trust Services Criteria categories with the CPA firm. Do not use a generic control library as a substitute for the agreed boundary.
  2. Inventory current controls. Identify the activities already performed across engineering, IT, people operations, legal and suppliers. Keep the list specific enough to test.
  3. Name the operators and decision makers. Assign who executes, reviews and escalates each control. Use a RACI for handoffs that regularly cross teams.
  4. Map evidence and failure response. Record the source, frequency, expected population, owner of exceptions and the way remediation will be rechecked.
  5. Walk through a sample. Take a real access review, change or vendor review and trace it from source data to decision and closure. Fix unclear ownership before the examination period accumulates more gaps.

This sequence works for a small founder-led team and for a larger enterprise with dedicated functions. The assignment changes with scale; the need for an accurate account of what happened does not.

What changed in the 2026 conversation about SOC 2 tools?

The AICPA continues to identify the 2017 Trust Services Criteria with revised points of focus in 2022 as the criteria resource. There is no reason to relabel those criteria “SOC 2 2026 controls.” AICPA’s 2026 SOC resources also emphasize the credibility of examinations and scrutiny of tool-provider arrangements. That reinforces a practical point: automation can organize evidence and surface gaps, but it cannot issue an auditor’s conclusion or make a weak control effective.

When evaluating software, check whether it preserves source context, timestamps and ownership. Ask how it handles missing data and exceptions. A promise that a platform will make an organization “SOC 2 compliant” without examining control operation and the CPA firm’s work is too broad.

How SPOG.AI supports control ownership and evidence

SPOG.AI connects evidence from identity, endpoint, cloud, vulnerability, ITSM and other systems to assets, controls, risks and owners. This helps teams see whether a selected control covers the intended population, where it has failed and who is responsible for remediation. Its governance and continuous control monitoring capabilities support exception tracking, accountable workflows and revalidation after a fix.

For a SOC 2 programme, that connected view can reduce the manual chase between a policy, a ticket and a system status report. The organization still defines its controls and report scope, and the independent CPA firm performs the examination. SPOG.AI helps the team manage the operating evidence behind those decisions.

See how SPOG.AI connects control owners, evidence and remediation.

Request a demo

Posted on

ISO Security Standards in 2026: Which Ones Matter for Your Organization?

An organization may use ISO 27001 to manage information security, ISO 27701 for privacy, ISO 27017 for cloud controls and ISO 22301 for continuity. The names often appear together in a security programme, but they do different jobs. Choosing the right standards begins with the risks, services and information the organization actually manages.

In 2026, the edition matters too. ISO/IEC 27701:2025 changed the privacy management landscape, ISO/IEC 27018:2025 updated guidance for personal information in public clouds, and ISO/IEC 27017:2026 updated cloud security guidance. An older list of ISO security standards can therefore point a team to the right topic but the wrong version or relationship between standards.

This guide explains where the main standards fit, which are management system requirements and which provide guidance, and how to turn their controls into evidence for cybersecurity compliance and risk decisions.

What are ISO security standards?

The International Organization for Standardization (ISO) and, for many technology standards, the International Electrotechnical Commission (IEC) publish standards that organizations can use to manage security, privacy, risk and resilience. A standard may set requirements for a management system or provide implementation guidance for a narrower subject.

That distinction affects certification. An organization may seek certification against a suitable management system standard through an independent certification body. Guidance standards do not all support standalone certification.

ISO itself does not certify organizations or issue certificates.

If a customer asks for “ISO compliance,” clarify which standard, edition, scope and form of assurance it expects.

If a customer asks for “ISO compliance,” clarify which standard, edition, scope and form of assurance it expects.

ISO standards also do not automatically satisfy a law or sector regulation. They can support a structured programme and provide reusable evidence, while specific legal and contractual duties must still be assessed separately.

Which ISO standards matter most for security in 2026?

StandardCurrent editionMain useRole in a security programme
ISO/IEC 270012022, with 2024 amendmentInformation security management system (ISMS) requirementsRisk-based governance and an independently assessable ISMS
ISO/IEC 270022022Guidance on information security controlsHelps select and implement controls referenced by ISO 27001 Annex A
ISO/IEC 277012025Privacy information management system (PIMS) requirements and guidanceManages risks and responsibilities around personally identifiable information
ISO/IEC 270172026Information security controls for cloud servicesClarifies customer and provider responsibilities and cloud-specific practices
ISO/IEC 270182025Protection of PII in public clouds acting as PII processorsSupports safeguards and accountability for cloud processing of personal data
ISO 223012019, with 2024 amendmentBusiness continuity management system requirementsHelps plan, exercise and improve continuity of critical activities
ISO 310002018Enterprise risk management guidelinesProvides broader principles and a common
ISO/IEC 420012023AI management system requirementsStructures governance of AI development, provision and use

This is a selection, not a requirement to adopt every standard. Start with the business question that needs an answer: information security governance, privacy, cloud assurance, continuity, enterprise risk or AI governance.

ISO 27001 and ISO 27002: Build the security foundation

ISO/IEC 27001:2022 defines requirements for an ISMS. It asks an organization to establish its context and scope, assess and treat information security risks, select controls, evaluate performance and improve. Its Annex A contains 93 reference controls. The organization determines necessary controls through risk treatment and records inclusion or exclusion in its Statement of Applicability (SoA).

ISO/IEC 27002:2022 provides more detailed guidance on controls. It is useful when teams need to translate a selected control into roles, technical measures and operational checks. ISO 27002 is a guidance standard; an organization is not certified to ISO 27002 in the way it may be certified to ISO 27001.

For 2026 operations, ask whether the ISMS reflects current assets, identities and suppliers. A SoA entry stating that a control is implemented should be supported by a defined scope and evidence. For example, an access control that works for older systems may miss newly deployed cloud applications.

The 2024 amendment to ISO 27001 asks organizations to consider whether climate change is a relevant issue in their context and notes that interested parties may have related requirements. It does not change the 93-control Annex A count.

ISO 27701: Privacy management changed in 2025

The 2019 edition of ISO/IEC 27701 was commonly described as a privacy extension to ISO 27001 and ISO 27002. That description needs an update. ISO/IEC 27701:2025 is an independent management system standard for a Privacy Information Management System (PIMS), according to ISO. It can be used on its own, while alignment with an existing ISMS may make implementation more efficient.

The standard is relevant to organizations acting as controllers or processors of personally identifiable information (PII). It helps define privacy responsibilities, risks, controls and evidence. It can support work on data protection obligations, but certification or alignment should not be presented as automatic compliance with GDPR or any other law.

If your programme still maps privacy controls solely as an ISO 27001 extension, review the current PIMS scope and how privacy decisions are governed under the 2025 edition.

ISO 27017 and 27018: Choose the right cloud guidance

ISO/IEC 27017:2026 provides cloud-specific information security control guidance based on ISO 27002. It addresses both cloud service customers and providers and helps clarify responsibility where infrastructure and operations are shared. The 2026 edition replaced ISO/IEC 27017:2015.

Use it to examine questions such as who approves administrative access, who maintains logging, who handles incidents and which party is responsible for a configuration. A contract may allocate responsibility, but operational evidence is still needed to show the control is working.

ISO/IEC 27018:2025 has a narrower privacy focus: protection of PII in public cloud services when the provider acts as a PII processor. Its 2025 edition aligns with ISO/IEC 27002:2022 and includes additional implementation guidance. It replaced the 2019 edition.

A company that consumes cloud services may use both standards in supplier assessment and control design. It should still verify the provider’s actual services, assurance scope and shared-responsibility arrangements rather than assuming a standards reference covers every workload.

ISO 22301 and ISO 31000: Resilience and risk

ISO 22301:2019, with a 2024 amendment, specifies requirements for a business continuity management system. It helps organizations identify critical activities, plan for disruptions, exercise responses and improve recovery arrangements. Security controls and continuity plans overlap, but an ISO 27001 ISMS alone does not demonstrate that every critical operation can recover to its required level.

ISO 31000:2018 gives principles and guidelines for managing risk across the enterprise. ISO lists it as the current published edition, although a revision is under development. It is useful for common risk language and decision-making beyond cybersecurity. ISO explicitly states that ISO 31000 itself is not a certifiable standard.

For a regulated or complex enterprise, use risk and continuity context to decide which security gaps matter most. An unprotected system supporting a critical business service may deserve a different response from a similar gap in a low-impact test environment.

ISO 42001: Add AI governance where AI is in scope

ISO/IEC 42001:2023 sets requirements for an AI management system. It is relevant to organizations that develop, provide or use AI systems. It addresses governance, objectives, risk and impact management, and continual improvement for AI activities.

An existing ISMS can contribute security processes, but AI governance also raises questions about system purpose, data, oversight and changing behavior. Determine which AI uses are in scope, who owns them and what evidence supports review. Do not assume that ISO 27001 certification automatically covers AI management requirements.

How to choose and implement the right standards

  1. Start with obligations and services. Identify customer contracts, applicable regulations, sensitive information, cloud dependencies, critical operations and AI use. Confirm the exact edition of a contract or assurance request names.
  2. Choose a management system foundation. ISO 27001 is a common starting point for information security. Add privacy, continuity or AI management system requirements where the organization needs them.
  3. Use guidance to design controls. Draw on ISO 27002, 27017, 27018 or ISO 31000 for their specific purposes. Record why a measure is needed and where it applies.
  4. Map shared evidence carefully. One access review or supplier assessment may support more than one framework, but the requirements and scope are not necessarily identical.
  5. Measure what is operating. Define owners, expected coverage, checks, exceptions and remediation for material controls. Revalidate after a fix or a significant change.

This approach can reduce duplicate collection while preserving the distinct intent of each standard. It also gives leaders a clearer view of the risks that remain after a policy has been approved or a tool has been deployed.

Where SPOG.AI fits

Standards are documented in policies and control libraries; their operating evidence is spread across IAM, cloud, endpoint, vulnerability, SIEM, ITSM and other systems. SPOG.AI connects security and IT signals with assets, controls, risks and ownership to help teams assess coverage and effectiveness, prioritize findings and track remediation through revalidation.

For example, one identity control may support the ISO 27001 ISMS, a privacy programme and a cloud assurance review. A shared evidence layer can show the same control’s actual population and exceptions, while the governance team maps that evidence to each requirement with its proper scope. The platform supports oversight and audit preparation; it does not itself award certification or replace legal assessment.

See how SPOG.AI connects framework requirements with live control evidence.

Request a demo
Posted on

ISO 27001 in 2026: What Matters Now

In 2026, the question for an ISO 27001-certified organization is no longer whether it is ready to migrate from the 2013 edition. That transition ended on 31 October 2025. The question is whether its information security management system (ISMS) still reflects the assets, identities, suppliers and risks it manages today.

A Statement of Applicability (SoA) may say that privileged access is controlled. But are newly created administrator accounts included? A backup policy may be approved. But have critical systems been added to the backup scope, and can the team show recent test results? These are the questions that turn ISO 27001 from a periodic documentation exercise into an operating management system.

This article explains what’s new in ISO 27001:2022 as background, then focuses on what security, IT and GRC teams need to maintain in 2026: current control scope, reliable evidence, accountable exceptions and verified remediation.

Which ISO 27001 version applies in 2026?

ISO/IEC 27001:2022 is the published edition for ISMS requirements, with Amendment 1:2024 applying to it. There is no separate ISO/IEC 27001:2026 edition. The amendment adds a climate relevance consideration to clause 4.1 and a note on interested-party requirements to clause 4.2. It does not add Annex A security controls.

The International Accreditation Forum set 31 October 2025 as the end of the transition period for accredited ISO/IEC 27001:2013 certifications.

Articles that still tell organizations to begin that migration or prepare for its deadline are dated. For a particular certificate, check its current status and scope with the issuing certification body.

In 2026, use the current clauses for the ISMS cycle: 6.1.3 for risk treatment and the SoA, 9.1 for monitoring and evaluation, 9.2 for internal audit, and 9.3 for management review. Operate the selected controls and act when the evidence shows gaps.

What should organizations focus on in 2026?

The accredited certification transition from 2013 has ended. Organizations maintaining ISO 27001 certification should now focus on whether the 2022-aligned ISMS stays accurate as assets, identities, suppliers and services change.

Keep the SoA connected to reality

The SoA is more useful when a control maps to an owner, scope, implementation and evidence source. If a new SaaS platform or critical business service appears, check whether the associated risks and controls are reflected. Review exclusions when circumstances change. A statement that a control is “implemented” should have a clear operational basis.

Test control coverage and effectiveness

Deployment is one step. Ask whether the control reaches all intended assets and whether it is healthy. For privileged access, for example, the team might compare protected accounts with all in-scope privileged accounts, investigate exceptions and prioritize exposed gaps. The same approach can be applied to endpoint protection, vulnerability remediation, backup and cloud configuration.

Track exceptions through to revalidation

Every material gap needs a defined owner and an outcome. Record the affected service, the business risk, the agreed action and the expected completion date. After remediation, test again and retain the result. An approved temporary exception should have a clear scope and review point so it does not become an invisible permanent state.

Reuse evidence across the ISMS cycle

Evidence collected during operations can support risk reviews, management reviews, internal audits and corrective action. Keep timestamps, asset scope and owners clear. An isolated screenshot from the week before an audit may show a state at one moment, but it rarely explains how the control behaved over the review period.

Why the 2022 update still matters

The 2022 edition updated the information security management system (ISMS) standard after the 2013 edition. Organizations had become more dependent on cloud services, distributed work, complex supply chains and rapidly changing technology. The revision aligned Annex A with ISO/IEC 27002:2022, the companion guidance on information security controls. It also aligned parts of the management system text with the common structure used in other ISO management system standards.

Its title now includes information security, cybersecurity and privacy protection. This wording does not create a separate privacy certification requirement.

The risk-based ISMS approach remains: understand risks, select controls, evaluate performance and improve.

What changed in ISO 27001:2022?

There are two different parts to consider:

Part of the standardWhat changedWhat it means in practice
ISMS requirements, clauses 4 to 10Mostly targeted wording and structural updates, including clause 6.3 on planning ISMS changesReview how your ISMS handles changes, interested parties, evidence and continual improvement
Annex A control reference set114 controls in 14 groups became 93 controls in four groupsRevisit your risk treatment mapping and SoA rather than assuming old control numbers still correspond one to one

The smaller number does not mean that organizations can drop 21 security practices. According to the International Accreditation Forum (IAF), the 93-control set includes 11 new controls, 24 resulting from merges, and 58 updated controls. Some earlier material was combined or rewritten. A control count is a description of the reference set, not a measure of an organization’s security coverage.

What changed in the ISMS requirements?

The mandatory management system clauses still address organizational context, leadership, planning, support, operation, performance evaluation and improvement. Several changes are especially useful to understand:

1. Planning changes to the ISMS. Clause 6.3 explicitly addresses planned changes to the ISMS. This concerns the management system itself, such as a change in its scope or operating approach. Annex A control 8.32 addresses changes to information processing facilities and systems; the two should not be treated as interchangeable.

2. Interested-party requirements. Clause 4.2 clarifies the need to determine which requirements of interested parties are addressed through the ISMS. The organization should be able to explain its decisions, not just maintain a list of stakeholders.

3. Risk treatment and the SoA. Annex A now references the ISO/IEC 27002:2022 control set. Organizations determine necessary controls through risk treatment, compare them against Annex A to avoid omissions, and document inclusion or exclusion in the Statement of Applicability.

4. Evidence and evaluation. Wording across parts of the standard was adjusted to clarify documented information used as evidence. Monitoring, internal audit, management review and corrective action still need to operate as a continuing cycle.

These are highlights, not a replacement for the standard’s complete text or an organization-specific gap review. The IAF characterized many management system changes as editorial, while identifying the revised Annex A and clause 6.3 as notable changes.

What are the four Annex A control groups?

The ISO 27001:2022 Annex A controls are organized as follows:

GroupNumber of controlsTypical areas covered
Organizational, section 537Policies, roles, supplier relationships, incident management and continuity arrangements
People, section 68Responsibilities before, during and after employment, awareness and reporting
Physical, section 714Physical access, facilities, equipment and physical security monitoring
Technological, section 834Identity, access, configuration, logging, networks, development and data protection

The four groups make the reference set easier to navigate. They are not four separate certifications or a directive to deploy every control in the same way. The SoA should record the controls selected through the organization’s risk treatment process, their status and the rationale for inclusion or exclusion.

For teams updating older documentation, a direct rename of control numbers is risky. A former control can be merged into a broader control, while a current control may address material that was spread across several earlier controls. Map the underlying risk, objective, implemented measure and evidence, then update the cross-reference.

What are the 11 new ISO 27001:2022 controls?

The 2022 revision identified 11 new controls within the 93-control Annex A set. They address areas including threat intelligence, information security for the use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding.

“New” describes their classification relative to the 2013 control set. It does not mean an organization necessarily lacked every corresponding practice before 2022. For example, many teams already monitored logs or managed cloud security under other controls and procedures. The useful task is to check whether the current risk treatment and SoA cover each applicable area, and whether its implementation can be demonstrated.

Consider three examples:

Cloud services: A supplier review alone may not show whether a newly deployed cloud account has the expected access, logging and configuration controls. Link the cloud service to an owner and to current operating evidence.

Configuration management: A documented baseline matters, but changes to actual systems can introduce drift. Define which assets are in scope, what states are acceptable and how deviations are handled.

Monitoring activities: Logging may be enabled but incomplete for critical systems. Check coverage, the health of data feeds, alert handling and the ownership of gaps.

This moves the discussion from whether a control appears in a spreadsheet to whether the selected measure operates where it is needed.

What did the 2024 amendment change?

Amendment 1:2024 changes clauses 4.1 and 4.2: organizations determine whether climate change is relevant to their context, and interested parties may have related requirements.

This does not add a climate-specific control to Annex A or turn the 93-control set into a different count. For an ISMS team, the practical question is whether climate-related issues are relevant to its context, services, sites, suppliers or interested parties, and how that determination is recorded. The effect will differ by organization. Avoid presenting the amendment as a new blanket technical security checklist.

How SPOG.AI helps connect controls to evidence

ISO 27001 controls are often defined in governance documents but operated in IAM, cloud, endpoint, vulnerability, ITSM and other systems. SPOG.AI connects security and IT evidence with assets, controls, risks and ownership, helping teams identify where coverage or effectiveness has changed. Its continuous control monitoring and GRC capabilities support visibility into gaps, exceptions, remediation and revalidation.

For a CISO or GRC leader, the useful view is more specific than “93 controls mapped.” It shows which selected controls apply to critical services, which are performing as expected, where exceptions remain and who is closing them. Certification decisions belong to the independent certification body; a platform supports the evidence and operational follow-through behind the organization’s ISMS.

See how SPOG.AI connects control performance with risk and remediation.

Request a demo
Posted on

ISO 27001 Change Management in 2026: How to Verify Every Change

In 2026, production changes move across cloud accounts, identity platforms, automated deployments and shared services. One approved update can affect several security controls and teams. A change ticket shows who authorized the work, but it may not show whether the resulting access, configuration and monitoring are in the expected state.

That is the practical challenge in ISO 27001 change management today. Teams need to assess and authorize changes, implement them safely, then verify the result across affected assets and controls. The decision at closure is whether the intended change worked and whether it left a material gap.

What should change management teams verify in 2026?

Before closing a material change, connect four pieces of information: the affected assets and business service, the control state expected after deployment, the actual evidence from operating systems, and the owner of any deviation. A cloud rule change might require exposure testing. A privileged access change might require an effective-permissions check across every account in scope.

Use the same record to show what was approved, what was deployed and what was verified. If the result differs from the approved plan, document the exception or remediation and test again. This makes the change process useful between audits, when new accounts, services and configurations appear most often.

How does the current ISO 27001 standard address change management?

ISO/IEC 27001:2022, with its 2024 amendment, is the current edition used for information security management systems (ISMS). There is no ISO/IEC 27001:2026 edition. Its Annex A control 8.32, Change management, addresses changes to information processing facilities and information systems. Clause 6.3, Planning of changes, separately addresses planned changes to the ISMS itself. These have different scopes.

Annex A is a reference set of controls used with clause 6.1.3, risk treatment and the Statement of Applicability (SoA). An organization should explain whether 8.32 applies and how it is implemented. ISO 27001 does not prescribe one ticketing tool, approval committee or universal template.

The accredited certification transition from 2013 ended on 31 October 2025. The 2024 amendment updated clauses 4.1 and 4.2 on context and interested parties; it did not change Annex A 8.32. Clause 9.1 addresses how the ISMS monitors, measures, analyzes and evaluates performance.

Why a completed change ticket is not enough

Consider a routine cloud network update. The request is logged, the service owner approves it, and the deployment succeeds. A later check shows that the new rule also made an administrative endpoint reachable from the internet.

The process produced an approval trail, but the security outcome was wrong. Effective change control connects the request to the affected assets, the relevant security controls, the implementation evidence and the post-change result. This helps teams spot unintended effects while the change is still fresh.

The same issue appears with IAM role updates, firewall changes, endpoint policy changes, patch rollouts, backup configuration and CI/CD deployments. A small change can alter control coverage beyond the system named in the ticket.

Where a change has several owners, the record should identify who verifies the affected service and its controls. Separate deployment, identity and monitoring tasks do not automatically add up to a checked security outcome.

A practical ISO 27001 change management process

The steps below form a practical ISO 27001 change management process. Your organization should adapt their depth to risk, criticality and its approved procedures.

1. Define the change and its scope

Record the reason for the change, the system or service, the requester, the owner, the proposed timing and the expected outcome. Identify dependent assets, identities, data flows and third parties where relevant. Classify routine, higher-risk and emergency changes so each follows the right path.

2. Assess security and business impact

Ask what could change in access, exposure, logging, availability, data handling and recovery. A change to a privileged role or internet-facing service needs more scrutiny than a low-risk update. Link the assessment to the business service and any relevant risks or controls.

The assessment should also consider what happens if the change fails. Could it interrupt a customer-facing service, disable an alert, widen access to sensitive data or prevent a backup from completing? These questions help teams choose meaningful pre-deployment tests and post-deployment checks. They also help an approver understand the risk being accepted.

3. Authorize and prepare

Use an approver with the right authority for the change. Document the implementation plan, tests, communication needs and a rollback or contingency plan suited to the risk. For emergency changes, define a faster authorization route and a prompt retrospective review in your own procedure.

4. Implement and retain evidence

Tie the work performed to the change record. Useful evidence may include a deployment or configuration log, the identity of the implementer, timestamps, test results and any deviations from the plan. Avoid relying on a ticket status alone as proof of the technical result.

5. Verify the result and follow through

Check whether the intended change worked and whether affected controls still meet their expected state. Record any failed checks, assign an owner, remediate and test again before closure. Where a risk must be accepted temporarily, record the exception, its approver, scope and review date under your organization’s process.

Match the verification to the change. A firewall update might need a reachability and exposure check. An IAM update might need a review of effective permissions and privileged account coverage. A backup change might need a successful job and, where appropriate, a restore test. The evidence should identify the affected population and the time of the check so a reviewer can tell what was actually verified.

Example: a privileged access change from request to closure

Suppose an operations team needs to move administrator accounts for a critical application into a new privileged access workflow. The ticket describes the intended migration, names the application owner and lists the accounts in scope. The risk assessment flags two concerns: an account could retain direct access outside the workflow, or a required service account could lose access and disrupt operations.

Before rollout, the team checks the account inventory, tests the access path and agrees on a fallback. Following approval, it records the configuration change and tests both successful authorized access and blocked access outside the approved route.

The post-change check finds that 94 of 100 in-scope accounts follow the new workflow. Four are documented service-account exceptions with an owner and review date. Two user accounts are unexplained gaps. Calling the migration “complete” would hide those gaps. A useful result records the 94% coverage, identifies the two accounts and their risk, assigns remediation, and tests their state again after correction.

These numbers are illustrative. The principle is to connect the approved change to the measured result, the exceptions and the verified closure of any finding.

What evidence supports an ISO 27001 audit?

ISO 27001 audit evidence should help show that the selected control operates as described in the SoA and supporting procedures. The exact sample and records will depend on the organization and audit scope. A useful record connects:

EvidenceWhat it helps demonstrate
Change request and classificationWhat was proposed and how it was routed
Impact assessmentWhich systems, services, risks and controls could be affected
AuthorizationWho accepted the planned approach
Test and deployment recordsWhat was checked and implemented
Post-change validationWhether the expected state and security controls were restored or maintained
Exception and remediation historyHow deviations were owned, resolved and rechecked

A documented ISO 27001 change management policy and procedure can make responsibilities and evidence requirements clear. The standard does not, however, require every organization to maintain a separately titled document with that exact name. What matters is a defined process that fits the ISMS, the selected controls and the organization’s risk.

For a sampled change, a reviewer should be able to follow the request, approval, implementation, validation and closure. Records across systems can form a trail if they share identifiers. Last-minute screenshots rarely show when a control was checked or what it covered.

Common change management gaps to watch for

  • A narrow asset list. The ticket names one server, but the change affects shared identities, cloud resources or downstream services. Expand the impact review to the actual dependencies.
  • Approvals without useful context. An approver sees the implementation task but not the possible effect on access or service availability. Include the material risks and proposed checks.
  • Successful deployment is treated as successful control validation. A pipeline can finish while logging, endpoint protection or a network rule moves into an unintended state. Check the relevant control after deployment.
  • Emergency changes that remain open. A fast fix is sometimes necessary, but the retrospective assessment and any follow-up work still need owners and due dates.
  • Exceptions with no expiry or review. A deviation can become permanent if its scope, owner and review date are unclear. Reassess it when the underlying environment changes.

These are process signals, not an ISO-prescribed list of nonconformities. Use them to test whether the change procedure works in your environment.

Measure whether change control works

Reviewing individual tickets is useful. Looking across changes reveals where the process itself needs attention. Possible measures include:

  • Unauthorized changes: changes detected in systems without a matching approved record.
  • Post-change control failures: changes followed by failed access, configuration, logging or availability checks.
  • Emergency change reviews: emergency changes awaiting retrospective review beyond the organization’s target time.
  • Remediation and revalidation: findings still open after a change, and findings retested after a fix.

Define scope and thresholds before using these measures. A percentage without a clear asset population, time window and exception treatment can be misleading. Use trends to improve the process and investigate high-impact outliers, not to claim that a single metric proves ISO 27001 conformity.

For example, “98% of changes had post-change validation” is useful only if the organization defines which changes require that check, what qualifies as validation and whether the remaining 2% includes critical services. Pair coverage measures with a review of the exceptions and the severity of any missed checks.

How SPOG.AI supports change assurance

Change evidence often sits across ITSM tickets, cloud platforms, IAM tools and security systems. SPOG.AI connects operational evidence with assets, controls, risks and ownership so teams can see whether a change affected control coverage or introduced a material gap. Its governance and continuous control monitoring capabilities help teams prioritize findings, assign remediation and revalidate the control state after a fix.

For example, after a privileged access change, a team can examine the affected identities and systems, compare the resulting control state with the intended requirement, track any exception and verify remediation. The change record remains part of the story; the resulting control state completes it.

Want to see how change evidence connects to control effectiveness?

Request a demo