In Part I, we argued that cybersecurity is expanding into something larger: resilience.

Detecting and stopping cyberattacks remains core to the cybersecurity function, but proving that the organization can continue operating when controls fail, systems drift, and ransomware spreads becomes necessary. This shift changes the work itself.

‍

The Cyber Resilience Engineer role is emerging because the old model never really worked and is now under serious challenge.

‍

Most organizations still prove resilience through disconnected manual processes: screenshots, spreadsheets, PDFs, exported reports, policy documents, and quarterly, if not yearly, audits. These activities are still useful but are rapidly becoming insufficient:  

‍

1. The information gets outdated almost immediately. A control can drift five minutes after a screenshot.
2. A backup can silently fail from one day to the next.
3. A cyber insurance policy requirement can change at renewal.
4. A recovery dependency can break after a software update.
5. An insurer can deny coverage because the policyholder cannot prove that the required controls were in place at the time of the incident.

‍

The organization assumes it is resilient. The reality often says otherwise.

‍

A typical proof workflow might look like the following:

‍

1. Compliance or security auditors request evidence.
2. Teams log into multiple systems manually to collect screenshots or export reports.
3. Then they update spreadsheets and reports.
4. Auditors, insurers, leadership, or customers review the evidence provided.
5. This manual process repeats itself again and again.

‍

Every cycle burns time, creates manual tasks, and potentially introduces inconsistencies.  

‍

Most importantly, even with significant efforts, the output is not that trustworthy. The process relies on static documents rather than the daily operational truth, and this gap has become impossible to ignore. Trust between the various parties is on the line.

‍

What Changes in a Model Focused on Proof and Resilience

‍

Cyber Resilience Engineers approach the problem differently. Instead of asking: “Do we have evidence?”, they ask: “Can the system continuously prove itself?”

‍

Instead of static evidence, they focus on activities that improve compliance and cybersecurity, overall building effective cyber resilience:

‍

• Controls are validated continuously.
• APIs replace screenshots.
• Recovery tests generate machine-readable results.
• Compliance and policy drifts are automatically detected
• Policy requirements are continuously assessed at the most granular level and become logical checks.
• Evidence becomes reusable.

‍

Proof stays current because it is continuously validated. And it’s trustworthy because it is machine-verified and protected. The workflow becomes operational instead of administrative.

‍

Example 1: MFA Validation

‍

The Old Way:

An auditor or insurer asks whether MFA is enabled. A security engineer logs in to Microsoft 365, takes screenshots, exports policy settings, stores PDFs, and then emails the evidence. This process has to be repeated for every system deployed with a variety of nuances - users with privileged access, users in specific countries, and so on.

‍

But worse, the evidence reflects only a moment in time. Onboard employees, interns, or contractors, and the collected evidence no longer reflects the operational reality.

‍

Static documents cannot prove that MFA remains enabled because the process will miss changes such as new exclusions, authentication methods that have become obsolete, and new privileged accounts.

‍

With Continuous Control Validation:  

A Cyber Resilience Engineer builds continuous validation against the live configuration state.

‍

This new model:

‍

• Checks MFA enforcement;
• Validates conditional access rules,
• Detects bypass scenarios,
• Monitors drift,
• Timestamps the evidence,
• Stores validation history in cryptographic tokens,
• Makes it easy to visualize gaps and posture changes.

‍

With the above, the organization can prove that MFA is in place where it needs to be and remains in place over time. This distinction matters during insurance underwriting, policy renewals, claims, and investigations.

‍

Example 2: Backup and Backup Recovery

‍

The old way: While the organization states, “We have backups”, recovery is based on dashboards, successful job status, and annual tabletop exercises.  Successful completion of a backup does not guarantee recoverability. Corruption, credential issues, dependency failures, network segmentation problems, or recovery orchestration gaps may only appear during an actual incident.

‍

With Continuous Control Validation:  

The Cyber Resilience Engineer continuously validates recovery:

‍

• Verifies backup integrity;
• Tests restoration workflows;
• Validates recovery time assumptions;
• Confirms critical dependencies;
• Measures operational readiness; and
• Automatically records recovery evidence.

‍

The organization graduates from “We believe recovery will work.” to “We continuously validate recovery capability.”

‍

Example 3:  Addressing Insurance Requirements

‍

The old way: Insurance applications are completed manually. Security teams, IT, insurance brokers, and underwriters exchange spreadsheets and questionnaires over email or maybe online. Answers often rely on stale dashboard exports and assumptions made without explicit verification across all systems, resulting in poor information quality.

‍

Months later, when an incident occurs, investigators attempt to reconstruct whether the controls actually represented in the application existed at the time of the incident. The reconstruction process can create enormous friction.

‍

With Continuous Control Validation, Cyber Resilience Engineers translate policy requirements into continuously validated controls.The process should:

‍

• Map insurability requirements directly to systems configurations and controls;
• Continuously validate insurance coverage conditions;
• Retain evidence history;
• Detect non-compliance, and
• Generate machine-readable proof.

‍

A systematic process, as described above, will eliminate ambiguity between the cyber posture asserted when an underwriter reviewed the account and what can be proven to have been in place at the time of the incident. It will change conversations about underwriting, renewals, and claims for the better.

‍

The real transition requires a mindset change.

Prevention, alerting, visibility, or control deployment remains necessary. But focusing on cyber resilience shifts the work towards operational continuity, recoverability, measurable trust, and verifiable proof.

This approach requires a different engineering mindset, hence a different title that highlights the core of the function. The Cyber Resilience Engineer treats security, backup, compliance, recovery, insurance, and governance as connected functions.  

‍

Where This Goes Next:  Many organizations have taken steps to formalize the function. As AI accelerates automation, evidence collection, validation, and recovery orchestration, cyber resilience engineering will likely become more central. Organizations that adapt will see their security team regain bandwidth to focus on operational continuity and the strategic evolution of their enterprise digital footprint.

‍

The future state is an environment that continuously proves itself. The teams building those systems are defining the next era of cyber operations.

‍

Spektrum operates at the forefront of this shift. Our platform is designed to support Cyber Resilience Engineers. Sign up for our free Resilience Journeys.