Continuous Verification vs. Annual Questionnaires
The Math

The Decay Problem

Security controls are not static. They are configurations in software systems managed by human beings under operational pressure. They change. They degrade. They are intentionally modified for convenience, compatibility, or cost reasons. They are unintentionally altered through software updates, vendor policy changes, and administrative errors. The assumption that a control verified at one point in time will remain in the same state for 365 days is demonstrably false.

Consider the lifecycle of a single control: multi-factor authentication on Microsoft 365. On Day 1, the IT director enables conditional access policies requiring MFA for all users. The cyber insurance application is completed. The questionnaire answer is "yes." The policy is bound. On Day 47, a new employee joins and is added to Azure AD. The onboarding process misses the conditional access group assignment. The employee has access to email without MFA. On Day 112, the CFO complains that MFA prompts are interrupting video calls. The IT director creates an exception for the "Executive" group. Six accounts now bypass MFA. On Day 198, a vendor integration requires a service account with email access. The service account is created outside the conditional access scope. On Day 284, an Azure AD update changes the default behavior of a conditional access policy. The IT team does not review the change log. Two conditional access policies are now in conflict, creating an unintended bypass path.

At no point did anyone intentionally disable MFA. The application answer was accurate on Day 1. By Day 284, it is materially inaccurate. The breach happens on Day 310. The claim is filed. The forensic investigation reveals the conditional access gaps. The carrier denies the claim based on material misrepresentation. The policyholder is stunned because they believed MFA was still fully deployed. It was — until it wasn't. And nobody noticed the degradation because nobody was checking continuously.

This is the decay problem. Controls do not fail catastrophically. They erode incrementally. Each individual change is small and reasonable in isolation. The cumulative effect is a security posture that diverges significantly from what was reported at binding. SecureWorld Chicago on May 20 will feature sessions addressing precisely this gap — the disconnect between reported security posture and operational reality.

Quantifying the Gap: The Mathematics of Point-in-Time

Let us quantify the problem with a simple model. Assume an organization has 20 discrete security controls that are relevant to its cyber insurance coverage. Each control has a monthly probability of degradation — the probability that the control state changes from "compliant" to "non-compliant" in any given month. Based on industry data from Verizon's 2025 Data Breach Investigations Report, the average monthly degradation probability for common controls is approximately 3–5%.

Using a conservative 3% monthly degradation rate, here is what happens to an organization that starts with all 20 controls compliant at the time of their annual questionnaire:

By the end of the policy period, an organization that was 100% compliant at application time has an expected compliance rate of 70%. Six of the 20 controls that the carrier believes are in place have degraded. The premium was calculated assuming 20 compliant controls. The actual risk is being borne on 14. The carrier is underpricing the risk by approximately 30% — not because of fraud, not because of bad faith, but because of the mathematical impossibility of capturing dynamic state with a static questionnaire.

The numbers get worse at higher degradation rates. At 5% monthly degradation — which is more realistic for complex environments with multiple administrators, frequent vendor changes, and regular employee turnover — the 12-month compliance rate drops to 54%. Nearly half of the controls reported on the application have degraded by the time the policy renews.

The Cost Comparison

Point-in-time verification has a direct cost: the questionnaire process itself. The policyholder's IT team spends 10–40 hours completing a comprehensive cyber insurance application. The broker spends 5–15 hours managing the process, clarifying questions, and assembling supplemental documentation. The underwriter spends 3–8 hours reviewing the submission and formulating follow-up questions. The total cost per submission — in fully loaded labor — ranges from $5,000 to $25,000 depending on the complexity of the organization.

And that investment produces a single snapshot that begins degrading immediately.

Continuous verification through the HATS Terminal has a different cost structure. The setup cost is near zero — three clicks per connector, no agents to install, no network changes. The ongoing cost is the HATS subscription, which starts at $20 per month per tenant for the base tier. The verification runs automatically at configurable intervals. The output is not a snapshot — it is a continuous stream of attested control states, each cryptographically signed and timestamped.

The economics overwhelmingly favor continuous verification. The direct cost is lower. The data quality is orders of magnitude better. The legal position for both parties is stronger. The claim denial risk — which represents the most significant financial exposure for the policyholder — is dramatically reduced.

How HATS Terminal Works

The practical implementation matters. A verification system that requires months of integration work, dedicated infrastructure, or specialized expertise is not a viable replacement for a questionnaire. The HATS Terminal was designed for the opposite: frictionless deployment that matches the simplicity of filling out a form while providing the rigor of continuous technical verification.

The setup process has three steps per connector. Step one: the policyholder selects the connector for their security tool (Azure AD, Okta, Google Workspace, CrowdStrike, SentinelOne, Microsoft Defender, Veeam, and seven others). Step two: the policyholder authenticates with the tool using their existing credentials. The Terminal requests read-only API access — it does not write, modify, or delete anything in the connected system. Step three: the policyholder confirms the connection. The Terminal begins reading configuration state immediately.

The entire setup takes less than five minutes for a typical three-connector deployment (identity provider, endpoint detection, and email security). There are no agents to install on endpoints. There are no firewall rules to configure. There are no network architecture changes. The Terminal communicates exclusively through the vendor's existing API — the same API the vendor provides for integration with SIEM, SOAR, and other security operations tools.

Auto-Derived Controls

Once connected, the Terminal does not ask questions. It derives control state automatically from the connected systems. This is the critical difference from a questionnaire. The questionnaire asks: "Is MFA enabled for all users?" The Terminal queries the identity provider API and returns: "MFA is enabled for 487 of 512 user accounts (95.1%). The following 25 accounts do not have MFA enabled: [list]. Of these, 3 are privileged accounts."

The level of specificity is not achievable through a questionnaire. No human completing an application would list 25 specific accounts without MFA — and even if they did, the information would be stale by the time the underwriter reviewed it. The Terminal provides this data in real time, updated at every attestation cycle, with each state signed cryptographically using post-quantum algorithms (ML-DSA-65).

The auto-derived controls cover the categories that generate the vast majority of claim denials: MFA enrollment and enforcement, EDR deployment coverage, email security configuration (SPF, DKIM, DMARC, anti-phishing policies), backup configuration (retention, immutability, offline storage), vulnerability management (patch status, critical vulnerability counts), and cloud security posture (public-facing assets, misconfigured storage, identity federation). Together, these controls address approximately 80% of the questions on a standard cyber insurance application.

The 12 Connectors

The Terminal currently supports 12 connectors spanning the major categories of security tooling. Identity providers: Azure AD (Entra ID), Okta, Google Workspace. Endpoint detection: CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint. Email security: Microsoft 365 Exchange Online Protection, Proofpoint, Mimecast. Backup: Veeam, Rubrik. Cloud security: AWS Security Hub.

Each connector reads configuration state through the vendor's public API. The read permissions are scoped to the minimum required for control derivation — user lists, policy configurations, deployment status, and configuration settings. The Terminal does not access content data (emails, files, databases) or telemetry data (alerts, logs, events). It reads configuration state only, which is the data needed to answer insurance application questions.

The /evaluate-risk Endpoint

For carriers and brokers who want to integrate verified control data into their underwriting workflows, the Terminal exposes a single API endpoint: /evaluate-risk. This endpoint returns a structured JSON response containing the attested control state, the overall risk assessment, and the quote readiness signal.

The quote readiness signal is a simple three-state indicator: QUOTE_READY (all critical controls are attested as compliant — the submission is ready for underwriting), NEAR_READY (most controls are compliant but 1–3 non-critical controls require attention — the submission can proceed with noted exceptions), or BLOCKED (critical controls are non-compliant — the submission should not proceed until remediation is completed).

This single endpoint replaces the entire back-and-forth cycle between broker, policyholder, and underwriter that typically takes 2–4 weeks. The broker calls /evaluate-risk, gets the result in under 60 seconds, and either submits the application (QUOTE_READY), identifies specific remediation items (NEAR_READY), or works with the policyholder to address critical gaps (BLOCKED) before submitting.

The Continuous Attestation Cycle

After initial setup, the Terminal runs attestation cycles at configurable intervals. The default is daily, but carriers or brokers can specify more frequent attestation for higher-risk accounts or less frequent attestation for stable, low-risk accounts. Each attestation cycle produces a complete control state assessment that is cryptographically signed and stored in the attestation ledger.

The attestation ledger is an append-only record of every control state assessment over the life of the policy. It provides the longitudinal data that neither questionnaires nor point-in-time scans can produce. When a claim occurs, the claims adjudicator can review the complete history of control states from binding through the date of incident. They can see exactly when a control changed, whether the change was reported to the broker and carrier, and whether any remediation was attempted.

This changes the dynamics of claims adjudication fundamentally. Instead of comparing a single application (completed 11 months ago by a human under time pressure) to a forensic report (generated 2 weeks after the breach by investigators with full access), the adjudicator compares the attested control state at the time of incident to the forensic findings. If the attested state shows MFA was enabled and the forensic report confirms MFA was enabled, the claim proceeds without dispute on that control. If the attested state shows MFA coverage dropped from 100% to 94% three months ago, the carrier had visibility into the degradation and either accepted the risk or required remediation. The claim cannot be denied on the basis of a surprise discrepancy.

The Mathematical Advantage of Continuous Verification

Let us return to the decay model with continuous verification. Instead of checking controls once per year, the Terminal checks daily. With daily attestation and immediate alerting when a control degrades, the maximum time a control can remain degraded without detection is approximately 24 hours. Compare this to the annual model where the maximum undetected degradation period is 365 days.

The impact on risk exposure is proportional. If we define "undetected risk exposure" as the product of the degradation probability and the detection interval, then:

For an underwriter, this 365x improvement in risk visibility translates directly to more accurate pricing. The premium can reflect the actual risk at any point during the policy period rather than the assumed risk at binding. The underwriter can offer more competitive pricing to organizations with continuous verification because the uncertainty premium — the loading applied to account for unknown degradation between assessments — drops to near zero.

What This Means for Renewals

The renewal process is where the advantages of continuous verification compound. In the current model, renewal involves re-completing the questionnaire, re-gathering documentation, and re-submitting to the underwriter. The entire process takes 4–8 weeks and produces another single snapshot that immediately begins degrading. The policyholder invests significant labor. The broker manages significant friction. The underwriter starts from a position of uncertainty because the prior year's data is stale.

With continuous verification, the renewal submission is pre-populated with 12 months of attested control data. The underwriter sees the current state, the trajectory over the policy period, and the specific periods where controls degraded and were remediated. The submission takes minutes instead of weeks. The underwriter has higher confidence in the data. The premium reflects actual risk rather than assumed risk.

The competitive advantage for brokers who offer this capability is substantial. The broker who delivers a renewal submission backed by 12 months of cryptographically attested data provides a fundamentally better product than the broker who delivers a 15-page questionnaire with self-reported answers. The underwriter prefers the verified data. The policyholder prefers the reduced labor. The economics favor every participant in the chain.

Addressing the Privacy Concern

The most common objection to continuous verification is privacy: "I don't want my insurance carrier to have real-time visibility into my security environment." This is a reasonable concern that deserves a direct response.

The HATS Terminal reads configuration state, not content or telemetry. It knows that MFA is enabled on 487 accounts. It does not know the identities of those account holders, the content of their emails, the files on their endpoints, or the data in their applications. It knows that EDR is deployed on 2,340 endpoints. It does not know what the EDR detected, what alerts were generated, or what incidents occurred. It knows that backup retention is set to 90 days with immutability enabled. It does not know what was backed up, what was restored, or what data was accessed.

The data shared is exactly the data the policyholder already shares on the application — but more accurate, more current, and more specific. If you are comfortable answering "Do you have MFA?" on a questionnaire, you are sharing the same information. The Terminal simply provides a verified answer instead of a self-reported one.

Furthermore, the policyholder controls which connectors are enabled and can disable any connector at any time. The data sharing is transparent, auditable, and revocable. The privacy position with continuous verification is arguably stronger than with the traditional model, where the application asks broad questions that the policyholder answers with broad statements that can later be interpreted against them.

The Industry Direction

The shift from point-in-time to continuous verification is not a theoretical possibility. It is an active trend driven by loss experience and technological capability. Munich Re's observation that underwriting has shifted to technical verification reflects what leading carriers are already building. The question is not whether continuous verification will replace questionnaires. The question is when, and who moves first.

The organizations that adopt continuous verification now benefit immediately through reduced questionnaire labor, better pricing (because verified state reduces the uncertainty premium), and stronger claim positions (because the attested state is on record). The organizations that wait will eventually be required to adopt it — the same way MFA was eventually required — but without the early-mover advantage in pricing and positioning.

Get started: Set Up HATS Terminal  |  Pricing  |  Self-Reported Controls Problem  |  Quantum Readiness Assessment