Why breaches got 12% more expensive in 2026, and how to avoid paying the bill

It’s Cybersecurity Awareness Month, and the industry has just received its annual invoice. The average data breach now costs 4.99 million, 12% more than a year ago and the highest figure in the 21-year history of IBM’s Cost of a Data Breaches study. Just a year ago, costs had fallen for the first time since the pandemic, and it looked like defenders were finally gaining ground. That lead is gone.

The easy explanation is that attackers got more sophisticated. The data tells a more uncomfortable story. Read IBM’s numbers alongside this year’s reports from everyone else, and five reasons stand out. Only one of them is really about attackers:

1. A breach is now a business outage, and the business pays most of the bill.
2. Attackers move faster than organizations can decide.
3. Organizations keep handing out access and never take it back.
4. AI adoption outran AI governance.
5. Complexity became a cost line of its own.

The flip side is the most useful finding of the year. Organizations that use security automation extensively paid 1.93 million less per breach and contained it 65 days faster. The bill is largely the price of slow decisions and inconsistent basics. Below, we walk through each reason: the business logic behind it, the numbers that prove it, what we see in our own managed services practice at Dedicatted, and what to do about it. We close with how to apply all of it on AWS, and a one-move-a-week plan for the rest of October.

Reason 1: A breach is now a business outage, and the business pays the bill

For years, breach cost was framed as an IT expense: forensics, patches, overtime for the security team. That framing no longer matches the data. In 2026, most of the money goes to two things that sit largely outside the security budget: running the organization in crisis mode while it figures out what happened, and the customers, orders and revenue lost while it does.

That changes who should care. When nearly two-thirds of the cost is detection and lost business, a breach is a business continuity event with a security trigger. The CFO and COO own as much of this risk as the CISO, and the business case for security should be written in their language: hours of downtime, customers lost, contracts at risk.

Attackers understood this before many boards did. Ransomware crews are increasingly not selling decryption keys; they’re selling silence. Their leverage is no longer your servers. It’s your customers’ trust. Which leads to the most important number in this section: not how many attacks you block, but how long a breach runs before you contain it.

The headline numbers

• 4.99 million is the global average cost of a data breach, a 12% jump and an all-time high. Spread across the breach lifecycle, that’s roughly CAD 1,100 per hour.
• 11.5 million is North America average, more than twice the global figure, driven by higher regulatory fines and business costs. Canada sits at 5.2 million, up from 4.84 million.
• Every industry got more expensive except one. Healthcare remains the costliest sector for the 13th year at 6.64 million, but actually fell 10.5%. Financial services follows at 6.29 million, then industrial and technology at 5.5 million each. Communications (+20%) and entertainment (+18%) saw the sharpest increases.

Where the money actually goes

We split breach costs into four buckets in our company and numbers prove this. In 2026, detection and escalation accounted for 1.64 million, lost business for 1.54 million, post-breach response for 1.36 million, and notification for 0.45 million. The first two make up 63% of the total. Post-breach response, which includes fines, legal costs and credit monitoring for affected customers, grew fastest at 15%.

The fastest-growing bucket is a signal in itself: as regulators and courts add to the bill, a slow or poorly documented response gets more expensive even when the attack itself is contained. Time is the multiplier:

• 247 days is the average time to identify (183) and contain (64) a breach, the first increase after five years of steady improvement.
• Breaches that took longer than 200 days cost 5.65 million, compared with CAD 4.32 million for those resolved faster.
• Who finds the breach matters. Internal teams detected 38% of breaches and resolved them in 209 days. Managed security providers found 31%, at the lowest average cost of 4.86 million. When the attacker was the one to announce it (17% of cases), costs rose to 5.12 million and the lifecycle stretched to 268 days.
• Recovery is improving: 42% of organizations say they fully recovered, up from 35%. But only 4% did so in under 50 days.

What’s being stolen

Customer PII was taken in 52% of breaches , while intellectual property, stolen in 32% of cases, was the most expensive at 196 CAD per record. Breaches of data stored across on-premises, private and public cloud environments together were the costliest (CAD 5.39 million) and the slowest to resolve (256 days). Public cloud breaches followed closely at CAD 5.38 million.

1. 39% of breached organizations were hit by ransomware, up from 24% in 2024.
2. Threatening brand reputation, through public shaming and leaks to the media, is now the most common extortion lever, used in 41% of ransomware cases. Encrypting systems was used in just 23%.
3. Encryption appeared in 78% of extortion cases, down from around 90% or more in every year from 2021 to 2025. Attackers increasingly extort without locking a single file.
4. The median initial ransom demand rose to 1.5 million, and the median payment to 500,000. Where negotiation happened, the gap between demand and payment narrowed by a median of 61%.

Find out how long a breach would run in your environment. Our AWS Well-Architected Framework Review assesses your workloads across all six pillars, including security and reliability, and gives you a concrete improvement plan.

Reason 2: Attackers now move faster than most organizations can decide

Most security programs were designed around a human tempo: a weekly vulnerability review, a monthly patch window, a change advisory board, an escalation that waits for the on-call lead to wake up. That tempo worked when exploitation took weeks. It doesn’t anymore.

The nuance is where the time actually gets lost. It’s rarely the tools. Detection technology kept improving: the average time to identify and contain a breach fell from 287 days in 2021 to 241 in 2025 . What hasn’t sped up is the decision. Who is allowed to isolate a production workload at 3 AM? Who approves an emergency patch outside the change window? Who calls the customer? In a 72-minute attack, a 30-minute approval chain means losing before the response even starts.

AI widens the gap from the attacker’s side. It doesn’t make attackers smarter so much as tireless and parallel. We are careful to note that AI mostly enhances existing techniques rather than creating new ones, but speed and scale are exactly what hurt defenders running at a human tempo. And with a frontier AI model announced in April 2026 that found thousands of high-severity vulnerabilities, the time from discovery to exploitation is set to shrink further.

The collapsing window

• 72 minutes: how long the fastest quarter of intrusions took to go from initial access to data exfiltration in 2025, down from 285 minutes in 2024. The share of incidents reaching exfiltration in under an hour rose from 19% to 22%.
• 2 days is the median time to exfiltration across all cases. Defenders need to be ready for both the sprint and the slow, patient intrusion.
• 15 minutes: how soon attackers begin scanning for a newly announced vulnerability. Exploit attempts often start before security teams finish reading the advisory.

Software exploitation is back on top

• In cloud incidents, exploitation of third-party software accounted for 44.5% of initial access in H2 2025, up from 2.9% in H1. Weak or missing credentials fell from 47.1% to 27.2%, and misconfigurations from 29.4% to 21%. Our interpretation: as default protections close the easy doors, attackers move to unpatched applications.
• Remote code execution alone grew nearly five-fold, from 2.9% to 13.6% of initial access.

AI-driven attacks are rising, and they cost more

Real-world examples: a ransomware operator’s deployment scripts showed signs of AI generation and ran across hundreds of systems; extortion negotiations showed templated, AI-like consistency; and an unsophisticated attacker used an AI model to write a professional-sounding extortion script.

• Deepfake and impersonation attacks made up 45% of those incidents, AI-enabled malware 19%, and AI-generated phishing 17%.
• 62% of AI-driven breaches hit critical infrastructure, especially financial services and energy.
• Attacks by AI-enabled adversaries rose 89% year over year. Spam volume rose 141%.

From the Dedicatted field: the 03:25 AM incident

Twelve minutes from alert to mitigation, at four in the morning, and the issue was resolved before the customer’s team woke up. Nothing about it was heroic. It worked because the monitoring thresholds, the escalation path and the mitigation step were all defined in advance, so nobody had to decide what to do under pressure. That’s the practical answer to a 72-minute attacker: the decisions are made before the incident, and only the execution happens during it.

Want this kind of 3 AM coverage for your platform? Our Cloud & Platform Managed Services include 24/7 monitoring, incident response and security baseline management for production cloud environments.

Reason 3: Organizations keep handing out access and never take it back

Every organization accumulates what we call permission debt. A contractor gets admin rights for a migration and keeps them. A CI/CD role gets broad permissions because it was faster to set up that way. A service account created in 2022 still runs on its original keys. None of these decisions is wrong in the moment. Together, they become the attacker’s map.

This is why identity now matters more than the network perimeter. Attackers who log in don’t trigger the alarms built to catch attackers who break in. They inherit whatever trust has been left lying around, and they look like a normal user, an automation job or a vendor integration while they do it.

From a business perspective, identity is where cost and risk line up most clearly. It’s one of the most common ways in, and identity and access management is also one of the most effective cost reducers IBM measured. Few security investments have such a direct line to the bill.

How attackers get in

• 83% of cloud and SaaS compromises investigated by Mandiant in H2 2025 started with an identity issue, and 73% were aimed at stealing data.
• 65% of initial access in IBM cases was identity-driven: identity-based phishing (22%), other social engineering (11%), previously stolen credentials (13%), brute force (8%), insider threats (8%) and IAM misconfigurations (3%).
• Help desks are a favorite target. 17% of cloud cases involved voice phishing, where attackers posed as employees to get IT staff to reset passwords and MFA, or posed as IT to get employees to authorize data export tools.
• Old credentials never die. In one case, attackers used AWS access keys suspected to have been exposed in a 2022 incident at a password management provider to break in.

How a foothold becomes a breach

• Identity weaknesses played a material role in nearly 90% of recent Canadian investigations, not only at entry but in privilege escalation and lateral movement.
• 99% of 680,000 cloud users, roles and services thatanalyzed had excessive permissions, some unused for more than 60 days. Every unneeded permission is a ready-made path for an attacker.
• Stolen session tokens and OAuth grants let attackers bypass MFA entirely and persist without logging in again.

Service accounts, API keys, automation roles and AI agents now often outnumber human users, and they tend to have broad permissions, long-lived credentials and little monitoring. Only 46% of breached organizations secure non-human identities in their AI workflows. Mismanaged secrets and keys add about CAD 199,000 to the average breach, and excessive privileges about CAD 177,000.

Not sure how much permission debt you’re carrying? Dedicatted Security Review On Demand reviews your IAM, KMS, CloudTrail and workload configurations and helps you set up GuardDuty, Inspector and Shield, with guidance from certified security engineers.

Reason 4: AI adoption outran AI governance

The business case for AI is real, and the pressure to deploy it comes from the top. Security teams are being asked to enable AI, not slow it down, and that’s the right instinct. But the 2026 data shows what happens when deployment moves faster than control: AI becomes a new class of insider that nobody onboarded. Agents get broad access to data and tools, models get connected to APIs and plug-ins, and nobody owns the audit trail.

The nuance most coverage misses is what these incidents actually are. They’re mostly not exotic model attacks. They’re the familiar problems, such as over-permissioned access, exposed APIs and cloud misconfiguration, showing up in a new place. That’s good news: organizations don’t need an entirely new security discipline to fix most of it. They need to apply the one they already have to AI.

Shadow AI deserves the same honest reading. When employees can’t get approved tools fast enough, they use their own. Banning tools rarely works; offering a safe, approved alternative usually does. Attackers, meanwhile, have started treating AI the way they’ve long treated admin tools like PowerShell: as something already inside your environment that they can borrow. We call it living off the AI land.

AI incidents are growing fast

• The most expensive types were model inversion, extracting sensitive data from a model (CAD 6.07 million), and prompt injection, manipulating a model’s output through crafted inputs (CAD 5.89 million).
• The most common causes, however, weren’t exotic model attacks. Cloud misconfigurations affecting AI workloads (27%) and compromised connected apps, APIs or plug-ins (27%) topped the list, alongside data poisoning (26%).
• An important nuance for anyone choosing a model: incidents happened at similar rates whether the model was open source (26%), third-party SaaS (26%) or a vendor model deployed on-premises (25%). Costs differed, from CAD 5.63 million for open-source models to USD 4.98 million for models trained in-house. In other words, governance matters more than model choice.

Governance hasn’t kept pace

• 92% of organizations with an AI-related breach lacked proper AI access controls such as role-based access and MFA. Across the whole study, only 40% applied access controls to AI models and data.
• Only 32% had policies in place to manage AI and detect shadow AI. Strict approval processes for AI deployments actually declined, from 45% to 38%. Only 19% said their governance and security teams coordinate.
• Shadow AI, employees using unapproved tools, was involved in 43% of security incidents, more than double last year’s 20%. Those incidents averaged USD 5.39 million, and about one in five led to a regulatory fine.

What we have seen in practice

1. Attackers hid prompt-injection text inside phishing emails to confuse AI-based email triage.
2. An insider used their company’s own AI assistant to research internal systems, write a denial-of-service script and debug it in real time.
3. A fake MCP server imitating a legitimate email integration quietly forwarded users’ emails to an attacker-controlled address.
4. Attackers exploited a code injection flaw in Langflow, a low-code platform for building AI agents, to deploy malware and ransomware.

The numbers above describe organizations that adopted AI first and secured it later. The cheaper path is the reverse. That’s why our AI Opportunity and Readiness Assessment treats security and governance as part of the readiness question. Over four weeks, we look at where AI can create real value and whether the data, identities and cloud foundations are ready to support it safely. The assessment is cloud-agnostic and can be AWS-funded for eligible organizations. Learn more about the assessment.

Reason 5: Complexity became a cost line of its own

There’s a pattern underneath the first four reasons: the attack surface is growing faster than anyone’s ability to see it. Every SaaS integration is a vendor relationship with access to your data. Every pipeline is a chain of trust. Every new environment, account or region is one more place where a control might be missing.

Our most hopeful finding sits right next to its most uncomfortable one. In more than 90% of the incidents it handled, misconfigurations or gaps in security coverage materially enabled the intrusion. Security is solvable, in other words, but most breaches come from inconsistency rather than attacker brilliance: a control deployed in one business unit but missing in another, logs that exist but nobody correlates, trust that was granted once and never revisited.

The supply chain is now the soft underbelly

• After a compromised Salesloft Drift integration let attackers into Salesforce with valid OAuth tokens, one organization discovered nearly 100 more third-party integrations connected to its Salesforce, many dormant or owned by former employees
• More than 60% of vulnerabilities in cloud-native applications sit in transitive dependencies, libraries your code pulls in without anyone choosing them.
• Supply chain breaches were the single biggest cost amplifier in IBM’s study, adding CAD 227,250, and among the slowest to resolve at 258 days. Security system complexity added another CAD 208,265, and lack of visibility into shadow IT

Case study: from laptop to AWS admin in under 72 hours

This incident is worth walking through step by step, because every link in the chain was preventable:

1. A developer’s code editor auto-updated a plug-in that relied on a compromised npm package. The package stole the developer’s GitHub token, and even tried to use a local AI tool to inventory configuration files.
2. Using that token, the attackers extracted a GitHub service account’s credentials from the CI/CD environment.
3. They abused the legitimate trust relationship between GitHub Actions and AWS (OIDC) to get temporary credentials for a deployment role.
4. That role could create CloudFormation stacks with IAM capabilities, so the attackers deployed a stack that created a new role with full administrator access.
5. With admin rights, they copied data from S3, terminated production EC2 and RDS instances, and made the company’s private GitHub repositories public.

Tight scoping of the OIDC trust and a deployment role without permission to create IAM roles would have stopped this at step 3 or 4.

Basic data hygiene is still missing

• 53% of breached organizations hadn’t encrypted sensitive data at rest and in transit, and another 10% weren’t sure.
• Only 26% have a post-quantum cryptography project, and 61% lack controls to monitor keys, certificates and algorithms across their environment, leaving them exposed to “harvest now, decrypt later” attacks.
• Attackers increasingly delete logs, snapshots and backups before or during extortion, to hinder investigation and recovery.
• Insiders are shifting from email to cloud storage, both corporate and personal, as their main way to take data out. In 35% of insider cases, they used more than one channel

From the Dedicatted field: the environment nobody was watching. One of the most common gaps we find has nothing to do with sophisticated attackers. In one engagement, a customer’s development and staging environments were reachable from the public internet. Production was locked down; the environments next to it were not. They often hold real data copies, reused credentials and debug features, which makes them an ideal back door.

The fix was simple: we placed those environments behind a VPN restricted to the customer’s offices and named, authorized individuals. No new platform, no large budget, just closing a door that should never have been open. It’s exactly the kind of inconsistency every leader points to in more than 90% of its incidents, and it’s why we recommend reviewing non-production environments with the same rigor as production.

Drowning in vendor questionnaires? Supply chain risk starts with knowing your vendors. Our AI-Driven Vendor & Third-Party Risk Assessment Automation reads questionnaires, SOC reports and contracts, scores risk against your own policies, and produces consistent, audit-ready reports for every supplier.

How to avoid paying the bill: what the cheapest breaches have in common

If the five reasons explain why breaches got more expensive, the same data shows which organizations avoided the increase. They don’t necessarily have the biggest budgets. They share three habits, and each one answers one of the reasons above:

• They buy speed, not just tools. Automation shortens the time a breach runs, and time is what drives the business cost in Reason 1 and the attacker advantage in Reason 2.
• They control access by default. Least privilege, encryption and security built into the delivery pipeline pay off the permission debt from Reason 3 and keep AI from becoming an ungoverned insider, as in Reason 4.
• They decide in advance who finds and handles a breach. Pre-approved playbooks, a clear owner for every finding, and either an internal team or a managed partner on watch, so the attacker is never the one who announces it.

There’s also a clear market signal: budgets are about to grow. The risk is that the money goes into more tools, which feeds Reason 5. Our view at Dedicatted is that the highest-return security spend in 2026 is automating the fundamentals and closing the decision gap.

Automation pays, but adoption is uneven

Organizations using security AI and automation extensively had an average breach cost of CAD 4.00 million, compared with CAD 5.93 million for those using none. That’s CAD 1.93 million saved, about CAD 400,000 more than last year, and breaches resolved 65 days faster (215 vs. 280 days).

Yet only 36% of organizations use these tools extensively. And they mostly use them to detect and investigate threats, not to prevent them: more than a third use no AI or automation at all in prevention. Half of breached organizations now run AI agents in their SOC, mostly for threat hunting (56%) and automated response (54%). Only 18% use them for vulnerability scanning and management, the exact area that faster, AI-driven exploitation targets.

A practical example of what automation makes possible: Google’s own automated forensic pipeline cut one investigation and containment from days to under 60 minutes, on an application its team had never investigated before. Without pre-configured access, Google notes, volatile evidence on a compromised instance can be lost entirely.

Notice what dominates the top of the list: building security into how software is shipped, and controlling who and what has access. Notice, too, that complexity is itself a cost driver.

Budgets are moving

• 64% of breached organizations planned to increase security spending. After learning about the new capabilities of frontier AI models, that rose to 85%.
• Planned investment priorities: hiring skilled specialists (45%), incident response plans and testing (43%), IAM (41%), and AI security and governance tools (34%).
• 74% have rethought where they deploy AI agents in the SOC, with planned use in vulnerability management doubling from 18% to 37%.

From the Dedicatted field: under 5 minutes, end to end. One of our managed services customers is an e-commerce business that is regularly targeted by DDoS attacks. For them, minutes of downtime translate directly into lost orders, the “lost business” category that makes up nearly a third of IBM’s breach cost. Here’s how the response is built:

• Observability first. Grafana, Prometheus, Loki and HAProxy metrics give one view of traffic, logs and application health, so an anomaly is visible in context rather than as an isolated alert.
• An escalation ladder that doesn’t rely on someone checking chat. Alerts go to chat first, then SMS and push notifications, then a phone call if nobody acknowledges.
• Standardized runbooks. Every runbook follows the same four parts: the trigger, how to validate it, the steps to resolution, and the criteria for escalating further. Any engineer on shift can execute it the same way at any hour.
• A pre-approved mitigation. For this customer, that’s a WAF challenge rule that filters malicious traffic while letting real shoppers through.

In one incident, the result was a 1.5-minute response and a 3-minute resolution: under five minutes end to end, with zero downtime. That’s our finding about automation and speed, made concrete. It’s also why our managed services SLAs are transparent to the minute, with P1 response times of 1 hour, 30 minutes or 15 minutes depending on the service tier.

Build security into how you ship. DevSecOps was the single biggest cost reducer in IBM’s study. With DevOps as a Service by Dedicatted, our cloud-certified engineers take ownership of your CI/CD, monitoring, backups and security, so good practice becomes the default, not an extra step.

If you run on AWS: avoiding the bill is mostly a configuration decision

As an AWS Premier Tier Services Partner and Managed Services Provider, Dedicatted works inside AWS environments every day, from early-stage platforms to regulated enterprises. Our consistent observation matches what these reports describe: AWS already provides native controls for nearly every risk in this factbook. The gap is almost never capability. It’s configuration, coverage across all accounts, and someone owning the findings.

One principle to keep in mind is the shared responsibility model. AWS secures the cloud itself; you’re responsible for what you build in it, including identities, permissions, configurations, data and the code you deploy. Every breach pattern above sits on the customer side of that line.

1. Close the exploitation window

• Amazon Inspector continuously scans EC2 instances, container images and Lambda functions for known vulnerabilities and prioritizes them by real exposure, so you patch what’s reachable first.
• AWS WAF with managed rule groups acts as a virtual patch at the edge while a full fix rolls out, which is exactly the 24-hour mitigation recommends.
• AWS Systems Manager Patch Manager automates patching on a schedule, instead of waiting on tickets.
• AWS Shield helps absorb the DDoS activity , our expects recommend these around major 2026 events such as the World Cup and US midterm elections.

2. Make identity the strongest layer

• Use AWS IAM Identity Center for workforce access, with phishing-resistant MFA, and avoid long-lived IAM user access keys wherever possible.
• IAM Access Analyzer finds unused roles, permissions and access keys, and resources shared outside your organization, which helps address Unit 42’s finding that 99% of cloud identities are over-permissioned.
• Service control policies and resource control policies in AWS Organizations set guardrails no single account can override, such as blocking the disabling of CloudTrail or the creation of admin roles outside an approved pipeline.
• For containers, use EKS Pod Identity or IAM roles for service accounts instead of static credentials in environment variables, the exact weakness exploited in the Kubernetes cryptocurrency heist we described

3. Lock down CI/CD trust

• Scope OIDC trust policies for GitHub Actions and other pipelines to specific repositories, branches and environments using conditions on the token’s subject claim, never the whole organization.
• Don’t give deployment roles permission to create IAM roles or attach administrator policies. Use permission boundaries so that any role a pipeline creates can’t exceed a defined ceiling.
• Alert on new IAM roles or policy attachments made by automation identities. In the 72-hour case above, that single alert would have exposed the attack.

4. Secure AI workloads

• Apply least-privilege IAM roles to Amazon Bedrock agents and applications, and limit which data sources and tools each agent can reach.
• Use Amazon Bedrock Guardrails to filter harmful content, sensitive information and prompt-based attacks.
• Log model and agent activity with AWS CloudTrail so AI actions are as auditable as human ones, and keep AI workloads under the same Config rules and Security Hub checks as the rest of your environment.

5. Protect the data and the evidence

• Encrypt by default with AWS KMS, and use Amazon Macie to find where sensitive data actually lives in S3.
• Move secrets into AWS Secrets Manager with automatic rotation.
• Protect backups and logs from tampering with AWS Backup Vault Lock and S3 Object Lock, and send CloudTrail logs to a separate, locked-down logging account.

6. Detect and respond at machine speed

• Amazon Detective speeds up investigations, and Amazon EventBridge with AWS Lambda or Systems Manager runbooks can automatically carry out the containment actions you’ve pre-approved, such as isolating an instance or disabling a compromised key.
• Amazon GuardDuty detects threats across accounts, workloads and runtime environments, and can correlate related signals into multi-stage attack sequences.
• AWS Security Hub centralizes findings and runs continuous posture checks against best-practice standards across all accounts.

The recommendations in this factbook come from the same practice that runs our managed services: 9+ years on the market, 140+ projects delivered, a team of around 80 engineers and specialists worldwide, multiple AWS Competencies, and SOC 2 and ISO 27001 certifications. The field stories above are real, anonymized customer cases.

Your October action plan: one move a week

Awareness is only the starting point. Here’s how we’d suggest turning the rest of this month into measurable progress, one focused move per week:

1. Week 1, Identity. List every human and machine identity with administrative rights, including CI/CD roles and AI agents. Remove anything unused for 90 days, rotate old static credentials, and enforce phishing-resistant MFA for admins. Give your help desk a verification process for MFA resets that can’t be bypassed by a convincing phone call.
2. Week 2, Exposure. Confirm that vulnerability scanning covers every internet-facing workload and container image, in every account. Set a target of 24 hours to mitigate and 72 hours to fully remediate critical vulnerabilities, and measure how often you hit it.
3. Week 3, Integrations and AI. Inventory third-party apps, OAuth grants, pipeline trust relationships and AI tools in use, approved or not. Assign an owner to each, revoke what nobody owns, and publish a short list of approved AI tools so people have a safe default.
4. Week 4, Response. Run a tabletop exercise based on a 72-minute breach. Who can isolate a workload or revoke a token without waiting for approval? Are your backups and logs protected from deletion? Who talks to customers if the attacker announces the breach first?