Category: #ISO 27001

Posted on

Backup and Recovery Checklist: What to Protect and Prove

The backup dashboard is green. A customer asks how quickly a critical service can be restored after an outage. The team finds the latest backup, but no record of a successful restore. The backup exists; the answer is still uncertain.

That gap is why backup compliance needs more than a schedule and a screenshot. Security and compliance teams need to know which services are protected, how much data could be lost, how long recovery could take, whether the backup survives a cyber incident and what happened during the last test.

This backup checklist works through three practical questions: What should be backed up? How often should it run? How can you prove recovery works? It is designed for teams managing ISO 27001, SOC 2 or other relevant assurance needs in 2026.

What should a backup program protect?

Start with the business service, not just its main database. A customer application may depend on application data, identity settings, infrastructure configuration, encryption keys, certificates and integrations. Restoring yesterday’s database will not bring the service back if the team cannot rebuild its environment or recover the secrets needed to start it.

List the components needed to restore each important service. Record where each one is protected and who can perform the recovery. Common categories include:

  • Business data: Production databases, files, transactions and customer records needed to resume the service.
  • System and application state: Configurations, virtual machines, containers or deployable images where these are needed for recovery.
  • Identity and access settings: Directory or identity configurations, roles and access policies that might be difficult to recreate safely.
  • Build and infrastructure definitions: Code repositories, infrastructure as code, deployment settings and documentation needed to rebuild.
  • Recovery dependencies: Keys, certificates and secrets, handled through appropriate secure recovery processes rather than casually copied into a backup store.
  • Required records: Logs, audit trails and other information that must remain available for investigation, operations or a defined retention obligation.

Not every component needs the same type of backup. A repository may already have a controlled recovery mechanism. A managed service may offer snapshots but require you to enable or configure them. A SaaS contract may define what the provider restores and what remains the customer’s responsibility. Check those arrangements rather than assuming the word “cloud” settles the question.

The most useful output is a service-to-backup map. For each critical service, show its important components, backup method, owner, recovery target and last tested result. This makes missing dependencies visible before an incident.

How often should backups run?

There is no single schedule that fits every organization and every system. Decide frequency from the impact of losing recent data and from any specific obligation that applies. The recovery point objective (RPO) is the point in time to which data needs to be recovered after an outage. If the approved RPO is four hours, the protection method must be capable of meeting that target under the expected failure conditions.

The recovery time objective (RTO) addresses how long the service can be in recovery before the disruption causes unacceptable harm. RPO and RTO answer different questions. Frequent backups can reduce potential data loss, but they do not guarantee a quick restore.

Consider two services. A billing platform that changes throughout the day may have a short RPO and require frequent snapshots or another suitable recovery method. An archive updated once a week may tolerate a longer interval. These are examples, not default schedules. The business owner and recovery team should agree on acceptable loss and downtime, then test whether the chosen design meets them.

Backups can also fail between scheduled runs. If an hourly job fails for half a day and no one notices, the latest usable copy may fall outside the RPO. Measure the age of the last successful, usable recovery point, not just the interval configured in a policy.

A practical backup control checklist

Use the questions below to review a service with its owner and backup operator. An unchecked answer becomes an action, with an owner and a date.

CheckQuestion the team should answerUseful evidence
ScopeDo backups cover each component needed to recover the service?Service inventory mapped to backup jobs or other recovery methods
FrequencyCan the most recent usable copy meet the approved RPO?Schedules, successful run history and recovery point age
RetentionAre copies kept for the period the organization needs?Approved retention setting and actual recovery points
ProtectionCould one compromised administrator delete production and every backup?Access rights, separation, offline or immutable copy settings
MonitoringDoes someone learn when a job fails or a source stops reporting?Alerts, review records and assigned follow-up
RestoreCan the team recover the data and the service within the intended window?Restore test, result and measured recovery time
ChangeIs backup coverage checked when a new system or data flow is added?Change record, owner review and updated scope

A backup job may pass one check and fail another. For example, it may complete every night but omit a newly created storage location. Treat coverage, job health, protection and restore results as separate questions.

How do you protect backups from the incident itself?

Recovery copies need protection from accidental deletion and malicious change. Ransomware can target online backups and the credentials that administer them. For critical data, consider an offline copy, immutable storage or another protected copy appropriate to the environment. Restrict who can change retention, delete recovery points or disable jobs. Protect backup credentials and encryption keys.

Test the isolation assumption. If the same account can administer production and remove every backup, one compromised account can defeat the recovery plan. A separate storage location alone may not help if the same permissions follow it.

What does a restore test need to prove?

A successful backup job shows that the job ran. A restore test checks whether the copy can be used. Start with one service and define the scenario: a deleted file, a failed database, a compromised server or a whole service unavailable. Pick a scenario that exercises the dependencies that matter.

Record the recovery point chosen, the person running the test, the environment used, the time taken and whether the restored data was correct. A technically completed restore is not enough if an application cannot read the data, a required identity configuration is missing or the result exceeds the RTO.

Tests should fit the importance and complexity of the service. A file-level restore may be appropriate for a narrow check. A critical service also needs an exercise that shows its components work together. When a test fails, identify the cause, assign a fix and repeat the relevant check. Keep the failed result in the record so the improvement can be traced.

Do not assume a fixed six-month test interval is required by every framework. Set a risk-based schedule, follow applicable obligations and test again when material changes affect the recovery design.

What counts as proof for an audit or customer review?

Start with the requirement and its scope. For an ISO 27001 information security management system, the organization selects necessary controls through risk treatment and documents them in the Statement of Applicability. Backup is addressed in Annex A control 8.13 of the current edition. For SOC 2, the evidence should match the system, selected criteria and examination period. A regulator or contract may add specific expectations.

Useful backup audit evidence shows four things together: the intended scope, the actual backup runs, how failures were handled and what happened in a restore test. It should have dates, named owners and links to the service or assets concerned.

A screenshot of a scheduled job can show configuration at one moment. It does not establish that every expected job ran throughout a period or that the data was recoverable. A better evidence trail connects the backup inventory to job history, alerts, tickets, restore tests and closure of exceptions.

Avoid promising a 100% job success rate as if every missed run were automatically a failed audit. The meaningful question is whether failures were detected, investigated and resolved in time to meet the organization’s recovery needs. Show the gap and the response honestly.

Where backup programs usually break

A new service is never added. An application owner deploys a new database, but its backup job is not in the original plan. Include backup coverage in onboarding and change reviews.

The job runs, but no one can restore the service. A restore test uncovers missing keys or configuration. Keep recovery dependencies in the service map and retest after the fix.

A failed job sits unseen. Alerts reach a mailbox with no clear owner. Give critical failures a response target, an escalation route and a way to confirm a usable recovery point exists.

Copies share the same weakness. One compromised identity can remove production data and every available backup. Review permissions, storage separation and protected copies.

Evidence is assembled at the last minute. The team has job logs but cannot tell which assets they cover or which failures were accepted. Connect the records during normal operations, not only when an audit begins.

How SPOG.AI helps teams see the backup control

Backup operations often sit in one system while the service inventory, incidents and risk decisions sit elsewhere. SPOG.AI’s continuous control monitoring approach connects defined controls to operational evidence so teams can see coverage, failed checks and follow-up across connected systems. Its governance and risk capabilities can relate those results to assets, owners, exceptions and remediation.

For a backup control, that means asking whether each critical service has the intended protection, when the last usable copy was created, what failed and who is fixing it. The backup and recovery tools still perform the jobs and restores. A connected control view helps the team understand whether the coverage and evidence support the decision it needs to make.

In 2026, the practical standard is simple: know what you must recover, set targets that reflect the business, protect the recovery copies and demonstrate that a restore worked. If a service cannot pass that test, the next step is an owned action, not a green dashboard.

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

Posted on

ISO 27001 Certification in 2026: What You Need to Prepare and Maintain

Getting ISO 27001 certification is a significant milestone. Keeping the certified information security management system (ISMS) accurate while people, cloud services and risks change is the longer job.

In 2026, organizations work against ISO/IEC 27001:2022 with its 2024 amendment. There is no separate ISO 27001:2026 edition. The accredited transition from the 2013 edition ended on 31 October 2025, so a new certification plan should focus on the current requirements and the actual systems and services in scope.

This guide explains the ISO 27001 certification process, the records teams should prepare, how the external audit works, and what it takes to maintain useful evidence after the certificate is issued.

What does ISO 27001 certification mean?

ISO/IEC 27001 sets requirements for an ISMS: a structured way to identify information security risks, select treatment measures, assign responsibilities, monitor performance and improve. Certification is an independent assessment of an organization’s ISMS against those requirements within a stated scope.

ISO does not issue certificates. An external certification body makes the certification decision. When choosing a body, check its accreditation for the relevant scope and verify a certificate’s current status through the issuing body or an appropriate certification database.

A certificate is not a guarantee that every system is free of vulnerabilities or that every Annex A control is deployed everywhere. Read its scope carefully. It may cover defined services, entities and locations rather than the entire company. For customers and partners, that scope is as important as the certificate itself.

Why pursue certification in 2026?

Organizations pursue certification to establish a repeatable risk management system and demonstrate it through independent assessment. A well-run ISMS can also clarify ownership, improve supplier discussions and make customer security reviews easier. These benefits depend on the system being operated, not merely documented.

The practical challenge is keeping the control picture current. A new application may rely on identities outside existing access reviews. A newly acquired business unit may change the ISMS scope. A cloud deployment may affect logging or backup coverage. Certification provides a governance structure for finding and handling these changes, while the organization’s own controls and follow-through address the underlying risk.

ISO 27001 certification requirements: What to prepare

The exact documents and samples depend on the ISMS scope and certification body’s audit plan. The following work forms a useful preparation path.

1. Define the ISMS scope and leadership responsibilities

Specify which products, services, teams, locations and information are covered. Identify interfaces and dependencies outside the scope, including suppliers and shared platforms. Leadership should establish the information security policy, objectives and responsibilities, and provide resources for operating the ISMS.

A narrow scope can be sensible if it accurately represents the service being certified. An artificial boundary that ignores a critical dependency creates confusion during risk assessment and audit sampling.

2. Assess risks and select controls

Set a repeatable risk assessment method and evaluate threats to confidentiality, integrity and availability. Decide how each material risk will be treated, who owns the decision and which controls are necessary. Review this when systems, suppliers or the business context change.

The Statement of Applicability (SoA) records necessary controls and the rationale for inclusion or exclusion from the Annex A reference set. It should connect a control to its implementation and evidence, rather than operate as a list of 93 boxes to tick. ISO 27001 uses risk treatment to determine necessary controls; it does not require identical control choices for every organization.

3. Put the ISMS into operation

Document and run the processes that support selected controls. Depending on scope, these can include access management, change management, incident response, vulnerability management, supplier oversight, backup and recovery, awareness, and secure development.

A policy is useful only when teams know how it applies. Define the population each control should cover, its owner, the systems that supply evidence and the way gaps will be handled. For example, an access review procedure needs a reliable account inventory and a record of decisions and follow-up actions.

4. Evaluate and improve

Monitor what the ISMS is meant to achieve, conduct internal audits and management reviews, and address nonconformities and improvement opportunities. These activities need enough operating history and evidence to be meaningful before the external audit. A last-minute set of policies with no evidence of use is unlikely to answer how the ISMS functions.

The 2024 amendment adds a climate relevance consideration to clause 4.1 and a note about interested-party requirements in clause 4.2. Determine whether those issues are relevant to the organization’s context and record the decision; the amendment does not add a new Annex A control set.

The ISO 27001 certification process, step by step

StageWhat the organization doesWhat the result should show
Readiness and gap assessmentCompare the current ISMS with the standard and identify missing practicesA scoped plan with owners and priorities
ImplementationTreat risks, operate controls and assemble evidenceWorking processes and traceable records
Internal audit and management reviewEvaluate conformity and performance before the external auditFindings, leadership decisions and corrective actions
Stage 1 external auditPresent the ISMS scope, documented arrangements and readinessFeedback on whether Stage 2 can proceed as planned
Stage 2 external auditDemonstrate implementation through interviews, observation and sampled evidenceAudit findings for the certification body’s decision
Surveillance and recertificationKeep operating and improving the ISMSOngoing assessment across the certification cycle

Stage 1 is commonly a readiness and documented-information review. Stage 2 examines whether the ISMS operates in practice. The auditor samples evidence, so a certification decision does not mean every transaction or asset was individually tested. Findings and corrective actions follow the certification body’s process.

The certification body, not a software vendor or consultant, decides whether to issue the certificate. Ask the body how it schedules stages, handles findings, defines the certified scope and verifies corrective action.

What counts as ISO 27001 audit evidence?

Evidence should show what happened, when, for which systems or people, and what was done about a gap. Depending on scope, examples include risk assessments and treatment decisions, the SoA, access reviews, change approvals, training records, vulnerability findings, incident exercises, backup tests, internal audit results and management review actions.

Link evidence to the requirement or selected control it supports. For privileged access control, the existence of a PAM tool is a starting point. An assessor may also need to understand the in-scope account population, current coverage, approved exceptions, unresolved gaps and follow-up. A record from an operational system can be more useful than a screenshot saved without date or context.

Evidence collection need not become a monthly audit rehearsal. Establish owners and sources during normal operations so the same records support risk decisions, internal oversight and external assessment.

How long does ISO 27001 certification take?

There is no universal schedule. Time depends on the ISMS scope, existing security practices, available owners, remediation work, how long controls need to operate before they can be sampled, and the certification body’s availability.

A smaller organization with mature processes and a focused scope may move faster than a large enterprise with multiple locations and shared services. Set a timeline only after a gap assessment and discussion with the certification body. Include time for internal audit, management review and corrective actions, not just policy writing and the two external audit dates.

How much does ISO 27001 certification cost?

Budget for the full cycle rather than one audit fee. Typical cost categories are internal staff time, control implementation, training, optional advisory or tooling support, the initial Stage 1 and Stage 2 audit, surveillance audits and recertification.

Costs vary with locations, headcount, technical complexity, audit duration, travel arrangements and the amount of remediation required. Obtain quotes against a defined scope from suitable certification bodies. Published generic price ranges may omit internal effort or make a broad scope look comparable to a narrow one.

What happens after certification?

Certificates commonly run on a three-year cycle, with surveillance audits during the cycle and a recertification assessment before renewal. Confirm the exact programme with your certification body.

Between audits, update the risk assessment, SoA and controls when the environment changes. Continue internal audits and management reviews. Investigate control gaps, assign remediation and verify the result. If the certified scope changes materially, speak with the certification body about how that affects the certificate and audit programme.

An access control may be effective at the certification audit and incomplete months later because new accounts were missed. Regular checks help discover that difference while there is still time to fix it.

ISO 27001 versus SOC 2

Organizations may be asked for ISO 27001 certification or a SOC 2 report. ISO 27001 certifies an ISMS within a defined scope. SOC 2 is an attestation report on controls at a service organization against applicable Trust Services Criteria. They serve different assurance requests, although some operational evidence can support both.

Let customer requirements and the services in scope guide the choice. If pursuing both, map shared control evidence carefully; do not assume that one certificate or report automatically satisfies the other’s criteria.

How SPOG.AI supports certification readiness and ongoing assurance

ISMS evidence is spread across identity, endpoint, cloud, vulnerability, ITSM and governance systems. SPOG.AI connects that evidence to assets, controls, risks and owners, helping teams see control coverage, exceptions and remediation in context. Continuous control monitoring can help reveal when a selected control stops working across the intended population, while GRC workflows support accountability and audit preparation.

For example, a control can be marked implemented in the SoA while recent evidence shows that some critical assets are missing protection. A connected view lets the team identify those assets, prioritize the gap, assign an owner and revalidate after remediation. The platform supports the organization’s ISMS; it does not issue or guarantee certification.

See how SPOG.AI connects ISO 27001 controls to current evidence.

Request a demo

Posted on

ISO 27001:2022 Update – Are You Ready for the New Compliance Requirements?

The latest ISO 27001:2022 update brings critical changes to information security, risk management, and compliance requirements. With a stronger focus on cyber resilience, supply chain security, and evolving threats, organizations must adapt quickly to maintain certification and safeguard sensitive data. Discover what’s new in ISO 27001:2022.

Cyber threats are escalating at an unprecedented rate. Studies indicate that organizations were facing an average of 1,876 cyberattacks per week in Q3 2024. That’s a whopping 75% increase from last year.

Thus, businesses can no longer afford a reactive approach to security. The latest update to ISO 27001, the global standard for information security management, is designed to address modern cyber risks with a more streamlined and proactive compliance framework.

The transition deadline is October 31, 2025, but companies that start preparing now will be in a stronger position to defend against emerging threats, align with other compliance frameworks, and avoid last-minute compliance chaos.

Let’s break down the key changes, what they mean for your compliance strategy, and the pitfalls to avoid.

A Deep Dive into the new changes in ISO 27001:2002

New Control Structure: From 114 to 93 Controls

One of the most significant changes in ISO 27001:2022 is the restructuring of Annex A security controls. The number of controls has been reduced from 114 to 93, consolidating overlapping controls and improving clarity.

These controls are now categorized into four logical groups:

  • Organizational Controls – These focus on governance, risk management, and policy implementation. Organizations must ensure that security is embedded at a strategic level, with leadership playing a central role in risk management.
  • People Controls – Human error remains one of the biggest security risks. These controls emphasize the importance of security awareness, employee training, and clearly defined security responsibilities.
  • Physical Controls – These address physical security measures such as facility access control, environmental protections, and security of on-premise data centers.
  • Technological Controls – These focus on cybersecurity best practices, including data encryption, endpoint security, and network monitoring.
ISO 27001:2002 18% less controls

Why does this matter?

  • Easier implementation – The revised structure makes it easier for organizations to map controls to their business processes.
  • Better risk alignment – With clearer categorization, businesses can focus on the controls that matter most to their specific risk environment.
  • Less redundancy – Consolidating controls eliminates overlap, reducing the effort needed for compliance management.

11 New Controls for Today’s Security Challenges

The evolving cyber threat landscape has introduced new challenges that weren’t adequately covered in the previous version of ISO 27001. The 2022 update adds 11 new security controls designed to enhance threat detection, improve data protection, and secure cloud environments.

Let’s break down the key additions:

  1. Threat Intelligence – Helps organizations proactively detect and respond to security threats by gathering intelligence from external and internal sources. This aligns with the broader industry shift toward proactive cybersecurity rather than reactive compliance.
  2.  Data Masking – Strengthens data protection by obfuscating sensitive information, making it unreadable to unauthorized users. This is crucial for GDPR compliance and helps reduce exposure in case of data breaches.
  3. Cloud Security – Addresses the growing reliance on cloud services and ensures that organizations implement security best practices for cloud-based environments. This control is particularly relevant as 83% of enterprise workloads are now in the cloud.
  4. Web Filtering – Blocks access to malicious or unauthorized websites, reducing the risk of phishing attacks and malware infections. Given that 91% of cyberattacks start with phishing, this control is essential for modern security strategies.
  5.  Security Monitoring – Implements real-time monitoring of security events to detect and mitigate threats before they escalate. This supports continuous compliance and aligns with SOC 2 and NIST CSF requirements.
  6. Secure Coding Practices – Encourages organizations to integrate security into the software development lifecycle (SDLC), reducing vulnerabilities in applications before deployment.
  7. Data Leakage Prevention (DLP) – Helps prevent accidental or malicious data exfiltration by monitoring and controlling sensitive data transfers.
  8. Information Security for Cloud Services – Expands beyond general cloud security to focus on vendor security assessments and shared responsibility models for cloud security management.
  9. Identity & Access Management (IAM) – Reinforces strong authentication and authorization measures to prevent unauthorized access.
  10. Configuration Management – Ensures IT systems are securely configured and maintained to prevent vulnerabilities.
  11. Monitoring Activities – Enhances log management and analysis to improve visibility into potential security incidents.

Why do these new controls matter?

  • They reflect real-world risks – Cyberattacks are more sophisticated than ever, and these new controls tackle modern security challenges like cloud security, data protection, and real-time monitoring.
  • They align with global compliance standards – Many of these additions strengthen ISO 27001’s alignment with SOC 2, GDPR, and NIST CSF, reducing the burden of managing multiple frameworks.
  • They support continuous security – The emphasis on real-time monitoring and proactive defense ensures organizations can stay ahead of threats, rather than just checking compliance boxes.

ISO 27001:2022: The Compliance Bridge You Didn’t Know You Needed

We understand that compliance can feel like a never-ending obstacle course. You jump through hoops for ISO 27001, then SOC 2, then GDPR, and before you know it, you’re drowning in security frameworks, each demanding its own set of controls, audits, and documentation.

But here’s the thing. ISO 27001:2022 isn’t just another certification to check off. If you use it the right way, it can actually simplify compliance across multiple frameworks. 

Think of it like a universal adapter for security standards. Instead of managing separate security programs for every regulation, you can use ISO 27001 as your single source of truth – one framework that aligns with SOC 2, NIST, GDPR, and more.

How does that work? Let’s break it down.

ISO 27001 Helps You Stop Doing the Same Work Twice

Most security frameworks overlap. They all require risk assessments, access controls, incident response plans, and vendor security reviews. The only difference is how they phrase it and who’s asking.

  • SOC 2 says, “Show me you protect customer data.”
  • GDPR says, “Show me you protect personal data.”
  • NIST says, “Show me your entire security program.”

At their core, they’re asking for the same thing. The problem is, companies often treat them as separate projects, leading to duplicate efforts, wasted resources, and compliance fatigue.

ISO 27001:2022 helps cut through the noise by aligning with these frameworks. Instead of creating three different risk management policies, you document one that meets all their requirements. Instead of running separate security audits for each standard, you map them to a single control set.

Overlap between ISO 27001:2002 - GDPR-SOC2


Most security standards share at least 70-80% of their requirements. They all focus on:

  • Risk management: Identifying and mitigating security threats
  • Access controls: Ensuring only authorized users handle sensitive data
  • Incident response: Having a plan when things go wrong
  • Continuous monitoring: Tracking threats and vulnerabilities over time

Rather than implementing separate processes for SOC 2, GDPR, and NIST, you can  streamline security efforts by creating one core security framework such as the ISO 27001:2002  to satisfy multiple regulations.

A compliance management tool can help you map overlapping controls, automate evidence collection, and maintain continuous compliance across multiple frameworks without duplicating efforts. 

Instead of managing separate security programs and redoing the same work for every regulation, a tool can align ISO 27001 controls with SOC 2, NIST, and GDPR requirements, ensuring that one framework satisfies many.

With automation, you can reduce human error, cut down compliance fatigue, and maintain continuous security monitoring rather than scrambling before an audit. A well-implemented system can pull compliance evidence directly from IT systems, ensuring tamper-proof documentation and real-time compliance.

By leveraging ISO 27001 as your security foundation and integrating it with a compliance management tool, you’re not just ticking boxes; you’re creating a scalable, efficient security strategy that grows with your business and keeps you ahead of evolving regulations.

Common Pitfalls to Avoid in the ISO 27001:2022 Transition

Transitioning to ISO 27001:2022 is not just a box to check. It is a strategic move that strengthens your security posture and ensures regulatory compliance. However, many organizations stumble during this transition due to poor planning, outdated processes, and underestimating the depth of changes. Below are some critical mistakes to avoid and how to stay ahead.

Transition to ISO 27001:2002

1. Delaying the Transition Process

Procrastination is a compliance killer. Many organizations assume they have plenty of time before the October 31, 2025, deadline. The reality is that a rushed transition increases the likelihood of gaps, failed audits, and compliance penalties. Updating documentation, implementing new controls, and training employees takes time.


Start now with a comprehensive gap assessment to identify what needs to change and create a phased implementation plan.

2. Treating Compliance as a One-Time Project

If your compliance strategy is built around annual audits, you are already behind. Many companies focus on getting certified but fail to maintain compliance between audits. This reactive approach exposes your organization to security vulnerabilities and audit surprises.


Shift to continuous compliance by embedding security into everyday business operations. Real-time monitoring, automated alerts, and periodic internal audits can help maintain compliance year-round.

3. Relying on Manual Processes and Spreadsheets

Still managing compliance with spreadsheets and email threads? That is like navigating a cybersecurity minefield with a paper map. Manual tracking leads to inefficiencies, inconsistencies, and a lack of real-time visibility.


Leverage GRC automation tools to centralize compliance management, automate control checks, and generate audit-ready reports effortlessly.

4. Applying a One-Size-Fits-All Approach to Risk Management

Not all security risks are equal. Applying the same level of security controls across all assets can either overburden teams with unnecessary measures or leave critical areas exposed.

Prioritize based on risk assessments. Identify high-risk assets and apply security controls accordingly to maximize protection where it matters most.

5. Ignoring Employee Training and Awareness

Your security is only as strong as your weakest link. A well-crafted compliance program means nothing if employees are not aware of security policies and best practices. A single phishing email or weak password can compromise an entire network.

Regular security training is non-negotiable. Conduct phishing simulations, workshops, and refresher courses to ensure employees stay vigilant against cyber threats.

6. Overlooking the New Annex A Controls

ISO 27001:2022 introduces 11 new controls focusing on modern threats like cloud security, threat intelligence, and web filtering. Many organizations assume that their existing security measures automatically cover these areas, leading to gaps.

Conduct a detailed control mapping exercise to align your security framework with the new requirements and avoid missing critical updates.

7. Failing to Involve Key Stakeholders Early

Compliance is not just an IT responsibility. It requires coordination across legal, HR, operations, and executive leadership. Many companies fail because they treat compliance as a siloed IT project.

Engage leadership and cross-functional teams early in the process to ensure organization-wide buy-in and smoother implementation.

8. Not Having a Clear Roadmap for Recertification

The transition to ISO 27001:2022 is not just about updating policies. It requires a structured approach to implementation, testing, and recertification. Some companies rush to update documentation without testing the effectiveness of their controls.

Develop a clear transition roadmap that includes internal audits, third-party gap assessments, and pre-certification reviews to ensure a seamless transition.

Are you ready to Transition to ISO 27001:2022?

Transitioning to ISO 27001:2022 is not just about meeting a compliance deadline. It is about strengthening your security posture in a rapidly evolving threat landscape. The updates bring a more streamlined, risk-based approach, helping businesses stay resilient against modern cyber threats. But managing this transition manually can be overwhelming, especially when juggling multiple frameworks like SOC 2, NIST, and GDPR.

This is where Spog.ai comes in. Instead of drowning in spreadsheets and scrambling for audit evidence, Spog.ai automates control mapping, real-time compliance monitoring, and audit readiness all in one platform. It simplifies compliance, reduces redundant efforts, and ensures that your organization is always ahead of security and regulatory changes.

The clock is ticking. Are you ready to transition seamlessly to ISO 27001:2022? Let Spog.ai take the complexity out of compliance so you can focus on what truly matters, securing your business.