Travelers CyberRisk Short Form: How to Prepare for Every Question

A practical, source-backed guide to the Travelers CyberRisk short form renewal application, including MFA, backups, encryption, incident response, and what Travelers can ask beyond the short form.

Travelers CyberRisk Short Form: How to Prepare for Every Question

Travelers matters for two reasons.

First, it remains one of the largest cyber insurers in the US. In NAIC’s 2024 cyber direct written premium ranking, the St. Paul Travelers group was second, behind Chubb and ahead of every other traditional market player except Chubb.[1]

Second, Travelers is attached to the most cited recent rescission story in cyber insurance. In Travelers v. International Control Services, Travelers alleged that MFA-related statements in the application and a separate MFA attestation were materially inaccurate; the case ended with the policy rescinded and declared void from inception.[2][3]

That is why Travelers’ short form deserves careful preparation even though the PDF itself is only three pages.

Travelers’ forms page says the short form and short-form renewal application are only accepted for businesses with revenues of $50 million or less and assets of $500 million or less.[4] That makes this the application many SMBs and lower-middle-market insureds actually encounter.

This guide walks through the short form question by question, explains what Travelers is trying to learn, and shows where teams should gather real evidence before anyone signs.

Before you touch Question 3, read the signature section.

Travelers says the authorized representative signs after reasonable inquiry and that the statements in response to the application are true and complete and may be relied upon by Travelers as the basis for providing insurance.[5]

That is the operational rule for the whole form:

  • do not answer from memory,
  • do not compress multiple systems into one easy “Yes,”
  • do not assume the short form means low underwriting consequence.

Q2: awareness of circumstances that could give rise to a claim

Question 2 asks, solely with respect to increased limits, whether the applicant is aware of any circumstance that could give rise to a claim under the CyberRisk coverage.[5]

This is a classic known-facts question. It is not a technical control question. It is a disclosure question. If the client is aware of an event, compromise, extortion demand, or privacy issue that could become a claim, treating that as “not final enough to disclose” can create problems later.

If there is doubt, get the broker involved and disclose carefully rather than taking a narrow view.

Q3: the security-controls checklist

This is where most of the real preparation lives.

Travelers asks whether the applicant has:

  • up-to-date, active firewall technology,
  • up-to-date, active anti-virus software on all computers, networks, and mobile devices,
  • a process in place to regularly download and install patches,
  • backup and recovery procedures for important business and customer data,
  • an incident response plan,
  • a disaster recovery or business continuity plan,
  • content controls for websites and media communications,
  • vendor security procedures,
  • and MFA for remote access to email and other systems containing sensitive data in bulk.[5]

The right way to read this section is not “check nine boxes.” It is “confirm nine control claims.”

Q3a: firewall technology

This is straightforward conceptually and annoyingly messy operationally.

Travelers is asking whether the applicant has active, current firewall protection. For many SMBs the honest answer is yes. But you should still avoid lazy confirmation.

Useful verification questions:

  • Is there still a supported perimeter firewall or cloud equivalent in place?
  • Is it actually the edge control for the office or environment in question?
  • Are there branch offices or acquisitions using unmanaged gear?
  • Is remote access bypassing the expected perimeter entirely?

If you cannot verify this from a management console or current network diagram, do not pretend a ten-year-old hardware refresh memory is enough.

Q3b: anti-virus on all computers, networks, and mobile devices

This question is written in “anti-virus” language because the form is older than the current EDR vocabulary, but you should prepare it as an endpoint protection question.

For Microsoft-heavy shops, Intune and Defender evidence can help. Graph’s managedDevice resource exposes device inventory and encryption/compliance properties, and Intune’s device-management tooling can confirm which devices are managed.[6][7] But even here, the challenge is scope: managed devices are not necessarily all devices.

That is the real underwriting question. Do you know the denominator?

If you say “Yes” because Defender is deployed on the devices you manage, but the environment also includes unmanaged contractor laptops, field tablets, or dormant systems outside MDM, that answer may be too optimistic.

Q3c: patching process

Travelers asks whether the applicant has a process in place to regularly download and install patches.[5]

The key word is process.

This is not asking whether the organization occasionally updates machines. It is asking whether there is a repeatable operating process.

A defensible answer usually requires:

  • a defined patch cadence,
  • ownership,
  • a system of record such as an RMM or MDM,
  • and a way to identify exceptions.

If your client’s real process is “we update when tickets come in,” do not dress that up as mature patch management.

Q3d: backup and recovery procedures

Travelers asks whether the applicant has backup and recovery procedures in place for all important business and customer data.[5]

This is a little broader and a little less precise than Coalition’s wording, but the underwriting intent is similar. Travelers wants to know whether the insured can survive data loss or ransomware without catastrophic recovery friction.

A strong backup answer should be backed by evidence on:

  • what data is actually covered,
  • how often backup jobs succeed,
  • where the backups live,
  • how recovery is tested,
  • and how quickly critical systems can be restored.

If the client only knows “we use Datto” or “we have Veeam,” that is not evidence. It is vendor identification.

Q3e: incident response plan

Travelers asks whether the applicant has an incident response plan to respond to a network intrusion.[5]

This is one of the most commonly overstated answers on cyber forms.

A contact list is not a full incident response plan. A vague ticketing escalation flow is not a full incident response plan. A PDF from three years ago that nobody has reviewed is not a strong incident response plan.

A defensible IR plan usually includes:

  • escalation roles,
  • internal and external contacts,
  • containment steps,
  • legal and notification considerations,
  • communications steps,
  • and some evidence it has been reviewed or tested.

Q3f: disaster recovery / business continuity

Travelers separates DR/BC from incident response.[5] That matters.

Incident response is about handling the security event. DR/BC is about keeping the business functioning and restoring operations.

Insurers split these because organizations often have one and not the other. The client who says “our incident plan is call the MSP” may still have no meaningful continuity plan for payroll, customer communications, or critical application downtime.

Q3g: lawful content controls

This question asks whether the applicant has controls to ensure the content of media communications and websites is lawful.[5]

For many non-media businesses, this is a lighter-control question. But it is still real for any firm that:

  • publishes marketing content,
  • manages customer-submitted content,
  • operates a public web presence,
  • or produces media or educational materials.

If the business publishes very little, the answer may be straightforward. If it is content-heavy, make sure there is actually a review workflow rather than a casual “marketing handles that.”

Q3h: vendor security procedures

Travelers asks whether the applicant has procedures requiring service providers with access to its systems or confidential information to demonstrate adequate network security controls.[5]

This is third-party risk management in one sentence.

You do not need a Fortune 500 vendor risk office to answer “Yes.” But you do need some actual procedure: contract language, onboarding review, questionnaires, required controls, SOC 2 review, cyber insurance requirements, or similar evidence.

If there is nothing beyond trust and convenience, the answer is weaker than most applicants think.

Q3i: MFA for remote access to email and other sensitive systems

This is the Travelers question everyone should slow down for.

The form asks whether the applicant has multi-factor authentication for remote access to email and other systems and programs that contain private or sensitive data in bulk.[5]

This is the most consequential question on the short form.

What Travelers is actually asking

Not whether MFA exists somewhere. Not whether users have registered the Authenticator app. Not whether the company owns Duo, Okta, or Microsoft Entra.

Travelers is asking whether remote access to email and sensitive systems is protected by MFA.

That has at least two separate components:

  1. email access,
  2. other sensitive systems and programs.

And it may span multiple control planes:

  • Microsoft 365,
  • VPN,
  • firewall-managed remote access,
  • RDP or remote access tools,
  • application-level admin consoles,
  • backup systems,
  • line-of-business systems with sensitive records.

Why M365 can still mislead you here

Microsoft gives you useful evidence, but not a one-line answer.

Security Defaults are a strong baseline, but Microsoft says ordinary users are prompted for MFA “when necessary,” not necessarily on every interactive event.[8]

Conditional Access is more precise, but it can include exclusion groups, and exclusions override includes.[9][10]

userRegistrationDetails tells you whether users are registered and MFA-capable, not whether every relevant path is truly enforced.[11]

Sign-in logs show whether MFA was prompted, how it was satisfied, and which Conditional Access policy applied, but Microsoft specifically warns that some events can look single-factor if an MFA claim was already satisfied earlier in the token flow.[12]

So a careful MFA answer requires reconciliation, not a portal glance.

What Travelers v. ICS teaches here

In the ICS complaint, Travelers alleged that ICS answered “Yes” on MFA-related application content and on a separate MFA attestation, but that in reality MFA only protected the firewall and did not protect the compromised server or other digital assets.[2]

This is exactly the failure mode Q3i is trying to prevent:

  • one access layer protected,
  • other sensitive systems not protected,
  • application says “Yes” as though protection is universal.

A better prep workflow for Q3i

Before answering, verify all relevant remote-access paths:

  • Microsoft 365 email
  • VPN
  • RDP / RD Gateway / remote support tooling
  • admin portals for critical systems
  • backup and infrastructure consoles if reachable remotely

If part of the environment sits outside Entra, verify that part outside Entra.

The clean answer is not “we use MFA.” The clean answer is “these access paths are protected, these are not, and here is the evidence.”

Q4 and Q5: PCI DSS and HIPAA

Travelers asks whether the applicant is currently PCI DSS compliant and whether it is HIPAA compliant.[5]

These are not “always say yes if we try hard” questions. If the client does not handle card data in scope, or does not operate under HIPAA, N/A can be the correct answer. If the client does handle cards or PHI, do not let compliance drift or partial controls get misrepresented as full compliance.

Q6: encryption questions

Travelers then asks whether the applicant encrypts private or sensitive data:

  • at rest in the database or on the network,
  • in transit,
  • on mobile devices,
  • on employee-owned devices,
  • and while in the care, custody, and control of third-party service providers.[5]

This is a compact section, but it covers multiple very different realities.

Q6a: at rest

This is wider than laptop encryption. Endpoint full-disk encryption helps, and Microsoft exposes device encryption status in Intune and Graph-managed device data.[6][7] But Q6a also touches database and network-resident data, which may require separate evidence from storage, application, or infrastructure teams.

Q6b: in transit

This is broader than email TLS. If the organization depends on SaaS, APIs, portals, file transfer, or encrypted web access, the question is really about whether sensitive data is protected in transit as a normal design expectation.

Q6c: on mobile devices

If corporate mobile devices exist, this is usually easier to defend with MDM evidence. If mobile access is ad hoc, unmanaged, or BYOD-heavy, the answer gets much harder.

Q6d: on employee-owned devices

This is where many SMBs discover they have quietly created a hard insurance question. BYOD email, files, and app access are common. The challenge is proving device-level encryption and control on personal hardware, not merely hoping the user’s iPhone is secure.

Q6e: with third-party providers

This is really a vendor-security and contract-language question. If you rely heavily on third-party processors or hosted systems, you want documentation around their encryption commitments and security practices rather than assumptions.

What Travelers can ask beyond the short form

One mistake buyers make is assuming the short form is the entire underwriting story.

Travelers’ public forms page lists the short form and short-form renewal form, but it also lists the long-form renewal application, a separate Multi-Factor Authentication Supplement, and supplements for social engineering fraud, healthcare and managed care, payment card exposure, and more.[4]

That is the practical lesson:

The short form is only the front door. If your risk profile, answers, requested limits, or industry characteristics warrant it, expect supplemental scrutiny.

A practical Travelers prep checklist

Before your next Travelers submission, gather this evidence set:

  1. MFA evidence for email and remote access
    Reconcile Entra, Conditional Access, exclusions, and non-Microsoft remote access paths.

  2. Endpoint protection coverage
    Know not only which tool you use, but which devices are actually covered.

  3. Patch-process evidence
    Be prepared to describe the workflow, not just the intention.

  4. Backup-and-recovery evidence
    Show coverage, success history, storage model, and ideally restore testing.

  5. IR/DR documentation
    Confirm plans exist, are current, and can be defended as real operating documents.

  6. Encryption scope
    Separate endpoint encryption from broader data-at-rest and in-transit controls.

The practical bottom line

Travelers’ short form is short by design. That does not make it low stakes.

It is a compact legal representation about the applicant’s cybersecurity posture, and Travelers says it may rely on those statements after reasonable inquiry.[5] The carrier’s own public materials also make clear that the short form sits inside a broader application ecosystem with supplements and more detailed forms when needed.[4]

So the safest way to prepare is not to “fill out the form faster.”

It is to verify the underlying controls before the form is completed.

BindLedger is built for exactly that layer: verify the control, record the evidence, map the result to the carrier question, and make the signer’s job safer.

Travelers prep starts before the PDF

The short form is the last mile, not the first one.

If you are renewing Travelers business, verify MFA, encryption, endpoint coverage, and backup reality before the form is completed. BindLedger is designed to make that step faster and more defensible by turning real control evidence into carrier-mapped answers instead of forcing MSPs to reconstruct the environment from memory.

Verify your email security posture now

Free carrier-mapped DNS scan. No signup required.

Scan your domain →

Or enter your email to get notified when full M365 attestation verification launches.

We'll send product updates and launch access when new controls go live.

Sources

[1] NAIC, “2025 Cybersecurity Insurance Report” (2024 direct written premium ranking): https://content.naic.org/sites/default/files/inline-files/2025_Cybersecurity_Insurance%20Report.pdf

[2] Travelers v. International Control Services complaint: https://www.americanbar.org/content/dam/aba/publications/litigation_committees/commercial/cases/2023/travelers-v-international-complaint.pdf

[3] Stipulated order rescinding the Travelers policy and declaring it void from inception (see publicly available case materials summarized in court records and news coverage): https://www.insurancejournal.com/news/midwest/2023/01/17/703344.htm

[4] Travelers, “CyberRisk Applications and Forms”: https://www.travelers.com/business-insurance/professional-liability-insurance/apps-forms/cyberrisk

[5] Travelers Casualty and Surety Company of America, “CyberRisk Short Form Renewal Application” (CYB-14203 Rev. 03-19): https://asset.trvstatic.com/download/assets/cyb-14203.pdf/ae74d9ea63c911eea2fad22664723407

[6] Microsoft Learn, “managedDevice resource type - Microsoft Graph v1.0”: https://learn.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice?view=graph-rest-1.0

[7] Microsoft Learn, “Monitor device encryption with Intune”: https://learn.microsoft.com/en-us/intune/intune-service/protect/encryption-monitor

[8] Microsoft Learn, “Security defaults in Microsoft Entra ID”: https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults

[9] Microsoft Learn, “Conditional Access: Users, groups, agents, and workload identities”: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-users-groups

[10] Microsoft Learn, “List policies - Microsoft Graph v1.0”: https://learn.microsoft.com/en-us/graph/api/conditionalaccessroot-list-policies?view=graph-rest-1.0

[11] Microsoft Learn, “List userRegistrationDetails - Microsoft Graph v1.0”: https://learn.microsoft.com/en-us/graph/api/authenticationmethodsroot-list-userregistrationdetails?view=graph-rest-1.0

[12] Microsoft Learn, “Use the sign-in logs to review Microsoft Entra multifactor authentication events”: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-reporting