RESILIAM INSIGHTS

Applicability

• ISO/IEC 27017 applies to cloud service customers and cloud service providers across public, private, hybrid, multi-cloud, and other cloud deployment models.
• Firms that traditionally consider themselves only cloud service customers may also act as cloud service providers where they offer hosted applications, client portals, managed solutions, or other cloud-based services to clients or other third parties.

What Are the Most Significant Changes?

The 2026 edition is more than a renumbering exercise. The principal changes include:

• Alignment with ISO/IEC 27002:2022: The standard now follows the organizational, people, physical, and technological control structure used by ISO/IEC 27002:2022. Several controls previously presented as separate cloud controls have been incorporated into broader controls covering areas such as configuration management, information deletion, monitoring, operating procedures, and network security.
• Greater attention to the cloud service chain: : A new control addresses the roles and responsibilities of cloud service partners. This recognizes that cloud services frequently depend on multiple providers, developers, brokers, auditors, and other parties, and that security responsibilities can be lost between them if they are not clearly allocated.
• A new focus on unauthorized cloud use: The revised standard adds a control addressing unauthorized access, data transfer, and other activity involving cloud services. For cloud customers, this brings shadow IT, inappropriate information movement, and anomalous service use more directly into the security program.
• Stronger operational and evidence expectations: The updated guidance more clearly addresses expectations for secure configuration, monitoring, backup and restoration, logging, incident reporting, data location, and the return or deletion of information when a cloud service ends. It also considers cloud service-derived data, not only data originally uploaded by the customer.

What Has Not Changed?

The structure has changed, but the central cloud security principles remain consistent:

• Shared responsibility remains fundamental: Cloud providers are responsible for the controls they operate, but customers remain responsible for defining their requirements, understanding what the provider does and does not control, and addressing any resulting gaps.
• ISO/IEC 27017 remains risk-based and supplemental: The standard complements ISO/IEC 27001 and ISO/IEC 27002 rather than replacing them. Organizations should apply its guidance according to their risks and their legal, regulatory, and contractual requirements.
• Cloud governance remains an ongoing responsibility: Selecting a provider or reviewing its certifications does not complete the process. Organizations must continue to evaluate provider capabilities, monitor material changes, and confirm that the service continues to meet their security requirements.

Looking Ahead

Organizations seeking alignment to the 2026 edition of ISO/IEC 27017 should begin by mapping their current controls to the standard and identifying where policies, responsibility matrices, supplier agreements, and supporting evidence require adjustment.

The larger question is whether cloud governance has kept pace with how cloud services are now being used. Multi-provider dependencies, rapid SaaS adoption, AI-enabled services, and increasing volumes of information created within cloud platforms make responsibility and visibility more challenging to manage. ISO/IEC 27017:2026 provides an updated benchmark for evaluating whether those risks are being addressed clearly and consistently.

On July 13, 2026, the Department of War immediately suspended the Phase II requirements of the Cybersecurity Maturity Model Certification (CMMC) program, previously scheduled to begin on November 10, 2026, and placed later milestones on hold while it conducts a 60-day review.

During the pause, acquisition programs may only require Level 1 or Level 2 self-assessments; they may not mandate external (i.e., third-party and government-led) certification.

The pause does not suspend underlying obligations to protect Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). Phase I self-assessment requirements, NIST SP 800-171 Rev. 2 obligations, and applicable FAR and DFARS cybersecurity clauses remain in effect.

Applicability

The suspension is relevant to defense contractors and subcontractors with current contractual obligations for CMMC Level 2 or Level 3 external assessment or who have been anticipating that such obligations would be forthcoming.

Organizations subject only to Level 1 or Level 2 self-assessment requirements are largely unaffected, as such obligations remain within the current Phase I framework, which is still valid.

What Changed?

The announcement changes the near-term compliance timetable in several ways:

• The November 2026 Phase II transition is paused: The next implementation phase and later milestones are on hold until further notice.
• New requirements for external certification may not be imposed: During the review, acquisition programs may issue requirements for Level 1 or Level 2 self-assessments, but not Level 2 or Level 3 external assessments.
• Existing requirements for external certification must be removed: Active solicitations containing the paused assessment requirements must be amended to remove them as soon as practicable, and existing contracts must have the paused requirements removed prior to the exercise of the next option period or during the next scheduled administrative modification.
• A 60-day program review is underway: A reform task force will perform a full review of the program and recommend a more scalable approach intended to reduce barriers for smaller businesses.
• Final rules and timing remain unresolved: Security leaders should expect more guidance after the review and avoid treating the pause as a permanent exemption.

What Has Not Changed?

The certification timetable changed; the underlying security and contract obligations did not:

• Self-assessments still apply: Level 1 self-assessments for FCI and Level 2 self-assessments for CUI may continue to appear in solicitations and contracts, and existing contracts with these requirements remain valid. Required affirmations and assessment records should remain current.
• NIST SP 800-171 Rev. 2 compliance remains the interim baseline: Compliance with NIST SP 800-171 will continue to be enforced through contractor self-assessments and select government-led assessments. A paused external assessment mandate does not excuse missing controls or unsupported self-assessment scores.
• FAR and DFARS obligations remain enforceable: Applicable FAR and DFARS clauses continue to require protection of covered information, including safeguarding CUI and incident reporting. Clients may also continue to impose cybersecurity expectations on their subcontractors.

Recommended Actions

The suspension should be viewed as additional preparation time, not a reason to pause readiness activities. Contractors should continue to:

• maintain accurate system boundaries;
• complete and update self-assessments;
• complete remediation plans;
• preserve evidence of control implementation; and
• monitor Department of War guidance.

Organizations that continue preparing during the review will be better positioned to respond to revised requirements without a costly restart or compressed implementation timeline.

On June 29, 2026, the Council of the European Union gave final approval to the Digital Omnibus on AI, following the European Parliament’s approval on June 16. The regulation has since been published in the Official Journal of the European Union and will enter into force on July 27, 2026. It will simplify certain requirements of the EU AI Act and delay the application of specified high-risk AI obligations, giving organizations additional time to prepare.

For most organizations, the primary takeaway is timing: certain high-risk AI obligations are expected to move to December 2, 2027 for standalone high-risk AI systems, and to August 2, 2028 for high-risk AI systems embedded into regulated products.

AI literacy, client confidentiality, security, privacy, and vendor governance remain current expectations regardless of whether specific high-risk AI obligations are delayed.

Applicability

The EU AI Act may apply to organizations inside or outside the European Union where AI systems are placed on the EU market, put into service in the EU, or where the output produced by the AI system is used in the EU. Professional services firms should therefore assess applicability based not only on office location, but also on whether their clients, users, matters, or AI-supported services involve the EU.

Most professional services firms will be “deployers” of vendor AI systems in the context of the EU AI Act, not developers or providers. The Omnibus should therefore be read through a practical procurement and governance lens: inventory AI systems, determine whether any are high-risk, invest in user training, and retain evidence of appropriate monitoring, review, and oversight.

What Are the Most Significant Changes to the EU AI Act?

In addition to delaying obligations for certain high-risk AI systems from August 2, 2026 to December 2, 2027 or August 2, 2028, depending on the category of system, key changes include the following:

• AI literacy remains required, but is more flexible: The EU AI Act requires organizations using AI to help personnel understand AI’s capabilities, limitations, risks, and appropriate uses. The Omnibus softens this obligation by requiring reasonable measures to support AI literacy, rather than requiring organizations to guarantee a specific level of AI competence for each individual user.
• High-risk classification may be narrowed for certain support tools: The Omnibus clarifies that AI used only for user assistance, performance optimization, service efficiency, automation, convenience, or non-safety quality control would not be treated as a high-risk safety component. This may reduce the likelihood that ordinary productivity, workflow, or administrative tools are subject to full high-risk AI requirements.
• Impact Assessments may be easier to combine with DPIAs: For high-risk AI systems, the Omnibus allows Fundamental Rights Impact Assessments (“FRIAs”) to cross-reference or incorporate relevant portions of GDPR Data Protection Impact Assessments (“DPIAs”). This may help professional services firms integrate review under the EU AI Act into existing privacy and vendor risk processes.
• Bias testing with sensitive data becomes more feasible: The Omnibus permits limited processing of special-category personal data for bias detection and correction where strictly necessary and subject to safeguards. However, it does not create a new general obligation to conduct bias testing.
• Generative AI acceptable use controls become more important: Prohibitions related to the use of AI systems for generating or manipulating non-consensual intimate material or child sexual abuse material were added. While these risks may be outside ordinary use cases for professional services firms, they reinforce the need for clear AI acceptable use rules and escalation procedures.

Why AI Deployers Should Still Monitor Provider Obligations

Organizations procuring and using AI systems will often be considered “deployers” under the EU AI Act. However, even deployers have ample reason to monitor provider-side obligations and related regulatory developments.

• Provider-side changes still matter to AI deployers: Some Omnibus changes primarily affect AI providers rather than deployers. Professional services firms should monitor these changes because they may affect required vendor documentation, contractual commitments, product timelines, transparency obligations, logging capabilities, and the firm’s ability to meet its own obligations as a deployer.
• Vendor readiness may affect deployer readiness: Even where an organization only functions as an AI user/deployer, it may need information from vendors to classify AI systems, complete impact assessments, understand system limitations, train users, and maintain appropriate oversight. Firms should consider whether their AI vendors can provide sufficient documentation and contractual support as AI Act requirements come into effect.
• Provider-like obligations remain a risk: Organizations may still assume provider obligations if they materially modify, rebrand, or use a high-risk AI system outside its intended purpose. Firms should control customization, integration, and non-standard uses of vendor AI systems.

Looking Ahead

In practical terms, the Omnibus gives AI deployers additional time to prepare for certain high-risk AI obligations, but it does not eliminate existing or future compliance expectations. Organizations should use the delay to build a defensible AI governance program, rather than waiting until the new deadlines approach. This includes maintaining an AI inventory, classifying AI systems, assessing potential impacts of AI systems, updating acceptable use and training programs, and confirming that vendors can provide the documentation and transparency needed to support responsible AI use

The Question That Changes the Conversation

There is a specific moment most organizations can identify in hindsight.

A long-standing client sends a security questionnaire as part of an annual vendor review. An RFP arrives with a section on information security controls that no one anticipated. A prospective client embeds a requirement for certification in their agreement.

For many organizations, the first instinct is to answer as best they can: pointing to internal policies, IT controls, or a recent risk assessment. That works, once. As the questions become more specific and the stakes rise, the gap between what an organization can demonstrate and what clients expect becomes harder to close.

The organizations that navigate this transition most effectively are not the ones that react fastest. They are the ones that had a certified, defensible program in place before the question arrived.

How the Legal Industry Responded

The legal industry went through this shift earlier than most, and the pattern is worth understanding.

In the late-2000s through mid-2010s, general counsel teams at major corporations started encoding security requirements into their outside counsel guidelines. At first, these were general expectations around data protection and incident response. Over time, they became specific: documented programs, third-party audit results, and in some cases, certification to standards such as ISO 27001 or proof of a SOC 2 attestation.

The firms that had built certified programs before those requirements arrived moved through client security reviews without friction. In competitive pitches, they answered security questions definitively. The firms that had not, found themselves in a reactive position. Certification timelines typically run six to nine months from kickoff to audit. That is not a gap that closes quickly.

That pattern did not stay in legal. It is repeating elsewhere.

The Two Frameworks Clients Are Asking About

ISO 27001 is the leading international standard for information security management systems. It requires a structured, auditable program for managing security risk across the organization, subject to annual surveillance and periodic re-certification. Because it is internationally recognized and independently verified, it satisfies client requirements across industries and jurisdictions.

SOC 2 is the most common U.S.-based framework for technology and service providers. It provides independent validation of controls across up to five Trust Services Criteria, with security as the baseline. Enterprise buyers in financial services and technology increasingly treat a SOC 2 Type II report as a procurement baseline, not a differentiator.

The right choice depends on the organization’s client base, industry, and markets. Some organizations pursue both. Either provides a substantially stronger position than an uncertified internal program when clients start asking.

How This Plays Out Across Industries

• Advertising and Marketing Agencies – Agencies operate deep inside their clients’ ecosystems, managing consumer data, running programmatic campaigns, and in many cases working within clients’ own technology platforms. Brand clients are tightening the conditions under which that access is granted. Security reviews and vendor qualification requirements are becoming standard at mid-market and enterprise brands. The expectation is that governance is already in place, not under construction.

• Wealth and Financial Management Firms – Wealth management clients are not only entrusting firms with data. They are entrusting them with financial assets, estate plans, and in some cases multigenerational wealth. Institutional investors and family offices are conducting more formal security due diligence on their advisors. The SEC has raised its expectations for registered investment advisors. A certified security program in this context is evidence that client interests are being protected with the same rigor applied to investment management.

• SaaS and AI Providers – In enterprise technology, certification has become a procurement gate. Buyers in financial services, healthcare, and professional services regularly require a SOC 2 Type II attestation or ISO 27001 certification before approving a vendor, regardless of product quality. For SaaS and AI providers, the business case is direct: deals that currently stall in security review move forward. The investment in a certified program pays for itself in closed business that would otherwise have been lost.

The Window Is Narrowing

In each of these markets, client-driven security pressure is increasing. The organizations that build certified programs now, before their client base formalizes the requirement, gain the same advantage that legal firms gained before outside counsel guidelines hardened into mandates.

That window does not stay open. As certification becomes more common in a market, it shifts from differentiator to expectation. The competitive benefit of early action is real, and it is time-bound.

For organizations already hearing early signals from clients, those signals are worth taking seriously. They are the same signals legal firms were receiving a decade ago.

What a Practical Path Forward Looks Like

The organizations that approach certification most effectively treat it as a program, not a project. Something built to last through re-audits and to scale as the business grows.

The starting point is an honest assessment: what controls exist, how well they are documented, and where the gaps are relative to the chosen standard. From there, the path involves systematic scoping, program design, control implementation across the organization, and audit preparation. It is structured, demanding work. The organizations that do it well come out with something that holds up when clients ask and when auditors return.

The signal that certification sends in the market is not about having passed an audit. It is about demonstrating that the organization treats client trust as something worth protecting with discipline.

That signal is becoming harder to send without it.