The massive AWS US-EAST-1 outage was the kind of event that stops entire industries in their tracks. It wasn't just a brief inconvenience; it was a global paralysis. For roughly fifteen hours, services we rely on daily—collaboration tools, logistics platforms, financial institutions, and countless mid-market businesses—were frozen.

It’s natural for the headlines to blame the vendor, and it’s tempting to treat the event as a rare, random technological flaw. But as advisers focused on reducing risk, we see something far more critical: the outage wasn't fundamentally a technical failure. It was a failure of governance and strategy that exposed a massive, invisible risk hiding in plain sight.

No technology is perfect, and human error is inevitable—even for the world’s most sophisticated cloud providers. Our job is to build a strategy that expects, and survives, the inevitable. This is the definition of true business resilience.

The Core Issue: What is Concentration Risk?

The real enemy revealed by the outage is Concentration Risk.

In simple terms, Concentration Risk is the danger of having all critical operational dependencies tied to a single vendor, a single platform, or a single geographic region. When you consolidate your mission-critical applications—your UCaaS, your CRM, your analytics, and your entire DR/Backup environment—all within one vendor’s ecosystem and, critically, in a single region like US-EAST-1, you’ve built yourself a beautiful, modern Single Point of Failure.

In the era of on-premise IT, your single point of failure was often a server in your closet. You could see it, touch it, and often smell it if it was overheating. Today, that single point of failure is disguised. It’s cleaner, more distributed, and far more complex to manage, but it remains one: one regional data center, one human error, or one localized major weather event can bring down your entire operation.

This wasn't an isolated incident, either. While the scale of the US-EAST-1 event was unprecedented, smaller, similar-issue outages are relatively common across all major cloud platforms. The reality is that the internet itself is a system of interconnected failure points. The problem isn't the cloud; the problem is the lack of strategic diversification within the cloud.

Why Governance is the Weakest Link

The most common question we hear is: "Why did so many companies expose themselves this way?"

The answer lies in two critical organizational pressures: Complexity Fatigue and Decision Paralysis.

1. Complexity Fatigue: When moving to the cloud, the sheer volume of choices, configurations, and pricing models can be overwhelming. It feels easier—less fatiguing—to just go "all-in" on one hyper-scale vendor and simplify the contract. This quick-fix simplicity, however, breeds a far more serious, long-term risk. You trade short-term convenience for long-term vulnerability.

2. Decision Paralysis: The pressure to move fast often leads to the implementation of the first viable solution rather than the most resilient one. The governance and strategic review process often fails to keep pace with the technical deployment, resulting in an accidental architecture where core services are unknowingly dependent on a single physical location.

The AWS event demonstrated that you can spend billions on the world's best engineering, but if your strategy doesn't account for the possibility of human error or a region-wide failure, you have not adequately reduced your risk.

Are You Exposed? An Honest Look at Mid-Market Vulnerability

While the major news focused on the massive companies impacted, the lesson for the mid-market is even more urgent. A large enterprise might have the internal resources and budget to switch vendors quickly or weather a multi-day financial loss; a mid-sized business may find itself in an existential crisis after such a period of downtime.

To translate this technological event into clear business outcomes, consider the operational cost of the outage:

• Financial & Operational Paralysis: If your core ERP, supply chain, or payment processing application lives in that single, affected region, you’re not just offline—you’re financially paralyzed. You can’t process payments, manage inventory, or close your books. The revenue stops, but the expenses don't.

• Customer Experience & Brand Damage: Your collaboration tools are down. Your customer support team can’t communicate internally or access the CRM system to track tickets. Customer trust—hard-won over years—can erode in hours when they see your core services are unreliable.

• The Contingency Illusion: This is perhaps the most dangerous exposure. If your disaster recovery (DR) or backup environment is strategically tied to the same single region as your production environment, you have an illusion of resilience, not the real thing. When the primary location fails, the DR fails with it, leaving you without a workable contingency plan.

The most pragmatic step you can take right now is to honestly assess your exposure with two simple questions:

1. Where do your mission-critical applications (CX, ERP, Data Analytics) actually reside? (Specifically, which cloud, and which geographical region within that cloud?)

2. Are your production and Disaster Recovery/Business Continuity strategies tied to the same geographic region?

If the answer to that second question is yes, you are currently operating with an unnecessary and unacceptable level of Concentration Risk.

The Strategy-First Approach to Resilience

The goal here isn't to fear-monger or advocate leaving the cloud. The cloud offers too much agility, scalability, and value to abandon. Our purpose is to provide clear-eyed, pragmatic advice: Cloud strategy must be strategy-first, not vendor-first.

The only way to genuinely manage Concentration Risk is through intentional strategic sourcing. This requires moving from an accidental, "Single-Cloud" dependency—which breeds risk—to an intentional Strategy-Cloud architecture that builds resilience by design.

The AWS outage was a gift: a free, massive, and expensive lesson in risk management paid for by the industry as a whole. The next step is moving from realization to resilient design.

What's Next?

Realizing the risk is the essential first step. It is the decision to move from a reactive position to a strategic one.

In Part 2 of this series, we will break down the practical, low-cost architectural shifts—specifically Multi-Region and Hybrid-Cloud strategies—that move your business from accidental dependency to intentional resilience. These are not massive IT overhauls; they are clear, strategic sourcing decisions that reduce risk and simplify complexity, giving you the peace of mind you deserve.

The CMMC Final Rule: What You Thought You Knew Just Changed

For government contractors, the Department of Defense's Cybersecurity Maturity Model Certification (CMMC) program has been a source of complexity, cost, and considerable anxiety. Since its inception, the regulation has evolved, leaving many in the Defense Industrial Base (DIB) struggling to keep up with its requirements and implications. The goal is clear: to secure the DIB against evolving cybersecurity threats and protect sensitive government information.

Beneath the dense regulatory language of the final rule, however, are several surprising, counter-intuitive, and impactful realities that every business in the DIB needs to understand. These aren't minor details; they are fundamental aspects of the program that challenge common assumptions and have significant strategic implications for contract bidding, IT investment, and risk management.

This article distills the official CMMC rule documents into a clear, scannable list of the most critical takeaways. It cuts through the noise to reveal what the Pentagon’s new cybersecurity rules really say and what they mean for your business. Our goal is to give you clarity and confidence to make quick, informed decisions.

Takeaway 1: "Self-Attestation" Isn't Dead—It Just Evolved

A core motivation behind the original CMMC program was to move the DIB away from the "self-attestation" model of security that the DoD had previously relied on for NIST SP 800-171 compliance. The perception was that self-reporting wasn't effective enough, necessitating a shift toward third-party verification.

The surprising twist is that the revised CMMC Program (often called CMMC 2.0) streamlined the model and reintroduced self-assessments as a valid compliance pathway. The final rule confirms that companies at Level 1 and a subset of companies at Level 2 are allowed to demonstrate compliance through annual self-assessments rather than a mandatory third-party audit.

This is a significant and pragmatic change that alleviates the immediate, immense cost and logistical burden a universal audit requirement would have placed on the DIB, especially on small businesses. This evolution represents a calculated, risk-based decision by the DoD, which has determined that for contracts involving less sensitive information, the risk of unverified compliance is acceptable when weighed against the practical realities and costs imposed on the defense industrial marketplace.

Takeaway 2: Perfection Isn't Required to Win a Contract

A common misconception about CMMC is that a contractor must have a perfect cybersecurity assessment score to be eligible for a contract award. This assumption has been a major source of stress for companies working toward compliance, as achieving 100% implementation of all security controls is a formidable task.

The final rule clarifies that this is not the case. An organization can be awarded a contract by achieving a "Conditional Level 2" or "Conditional Level 3" CMMC status. To qualify, a company must achieve a minimum score equal to 80% of the maximum score on a CMMC Level 2 or Level 3 assessment. All unmet requirements must be documented in a Plan of Action and Milestones (POA&M).

Critically, the organization has a 180-day deadline from the date of the conditional assessment to close out the POA&M and meet all remaining requirements. This is a significant and practical concession from the DoD, allowing companies to win business while still finalizing their compliance efforts.

Takeaway 3: The Government Won't Tell You Exactly What to Protect

One of the most persistent areas of confusion for contractors is determining what information, exactly, constitutes Controlled Unclassified Information (CUI). Many have asked the government for clearer definitions, guidance, and contract-specific lists to help define the scope of their CMMC efforts.

The counter-intuitive reality is that the DoD has officially stated this is outside the scope of the CMMC rule, placing the primary responsibility for identifying CUI squarely on the contractor. The rule's commentary includes a direct and unambiguous response to industry requests for guidance:

The CMMC Program will not provide CUI guidance materials to industry as it is outside the scope of this CMMC rule.

The document further clarifies that official DoD policy states, "The authorized holder of a document or material is responsible for determining, at the time of creation, whether information in a document or material falls into a CUI category." This places a significant burden on contractors, who must become experts in data classification to accurately define the scope of their own CMMC assessments.

Takeaway 4: The Biggest Costs of CMMC Aren't Considered "CMMC Costs"

The high cost of CMMC compliance is a major concern across the DIB. However, the DoD's official position on what constitutes a "CMMC cost" may come as a surprise. The costs to implement the required security controls for Level 1 (from FAR 52.204-21) and Level 2 (from NIST SP 800-171) are not considered costs attributable to the CMMC rule.

The government's rationale is that these implementation requirements were mandated years earlier, with a deadline to implement the NIST SP 800-171 controls set back in December 2017. Therefore, from the DoD's perspective, companies should have already incurred these implementation costs. The only new costs officially attributed to CMMC Levels 1 and 2 are for the assessment and affirmation activities required to verify that those pre-existing requirements have been met. The DoD reinforces its perspective on the necessity of these costs with a powerful statement:

The cost of lost technological advantage over potential adversaries is greater than the costs of such enforcement.

Takeaway 5: Your Cloud Provider Is Part of Your Audit

A company’s CMMC compliance boundary does not end with its own on-premises servers and workstations. If an organization uses an external Cloud Service Provider (CSP) to process, store, or transmit CUI, that CSP is unequivocally part of the CMMC assessment scope.

The final rule specifies a clear and impactful requirement for these providers: the CSP must meet the FedRAMP Moderate baseline or an equivalent standard. The rule documents are explicit on this point, stating the following:

...the DoD is not willing to assume all the risk of non-FedRAMP Moderate Equivalent CSOs when the CSO is used to process, store, or transmit CUI.

This effectively makes vendor selection a compliance decision, not just an IT one. The contractor is ultimately responsible for ensuring its entire CUI data chain—including services provided by third parties—meets DoD's stringent security standards.

Takeaway 6: The "COTS Exception" Is Narrower Than You Think

The CMMC rule provides a well-known exemption for contracts that are solely for the acquisition of Commercially Available Off-the-Shelf (COTS) items. This has led some to believe that if they sell COTS products, they are exempt from CMMC entirely.

However, there is a critical and surprising nuance in this rule. The source text clarifies: "The exemption does not apply to a contractor's use of COTS products within its information systems that process, store, or transmit CUI."

A simple example illustrates this crucial distinction:

• A company whose contract is solely to sell COTS laptops directly to the DoD might be exempt from CMMC for that specific contract.

• However, if that same company uses those same COTS laptops in its own corporate network to perform work on a different DoD contract that involves CUI, then its network is subject to CMMC requirements.

The exemption applies to what is being sold, not to what is being used to perform contract work involving sensitive data. This is a crucial detail that could easily lead to a failed assessment if misinterpreted.

Conclusion: A New Era of Accountability and Pragmatism

The Cybersecurity Maturity Model Certification program represents a fundamental shift in the DoD's approach to securing its supply chain. It moves the DIB from a model based on trust and self-attestation to one centered on verification and accountability. Yet, as these takeaways reveal, the final rule is not a rigid, one-size-fits-all mandate. It includes pragmatic allowances—such as self-assessments and conditional certifications—that acknowledge the business realities faced by the thousands of companies that support the U.S. warfighter.

The rules are now set, and the phased implementation is underway. With this new era of accountability beginning, the true test now begins: will this landmark regulation successfully raise the DIB's security baseline to protect against advanced threats, or will it create unforeseen obstacles for the very innovators the DoD relies on? The path forward requires clarity, and recognizing these six realities is the first step toward confident compliance.