NetGuard Plus Renewal Application: What Changes at Renewal

Renewing a Tokio Marine HCC NetGuard Plus cyber policy is not a light administrative process. The easiest mistake brokers make is treating cyber renewal as a compressed replay of new business—a simple form refresh with the assumption that "everything stays the same." The public NetGuard Plus renewal application shows otherwise [1]. TMHCC publishes separate renewal forms for accounts below and above $100 million in revenue, and that distinction alone signals that renewal is a distinct underwriting event, not an extension of expiring coverage.

Understanding what changes at renewal—and what doesn't—prevents application delays, unnecessary RFIs, and terms degradation. More importantly, it ensures your clients understand their obligations and aren't caught off-guard by tighter renewal requirements.

What Stays the Same: The Core Control Framework

One of the most important things to understand is that a significant portion of the NetGuard Plus renewal form mirrors the new-business application [1]. The core control families remain in view at renewal:

• Remote-access MFA (VPNs, RDP, RDWeb, RMM tools)
• Privileged-access MFA and account lockout policies
• Email MFA for web or non-corporate device access
• NGAV (next-generation antivirus) deployment across all endpoints
• EDR (endpoint detection and response) with centralized monitoring
• Backup design: encryption, immutability, offline separation
• Phishing training and testing programs
• Wire-transfer verification controls
• Critical vendor identification and service dependencies
• Network security ownership and accountability

This continuity matters because it tells you that renewal is not just a claims-history review. TMHCC still wants the current control picture. If the MSP changed the security stack, if backup architecture improved, if MFA expanded, or if coverage gaps persist, renewal is where the truth has to be organized and stated clearly [1].

The renewal form also still requires identification of the person within the insured organization responsible for network security, whether that role is internal or outsourced, and—if outsourced—confirmation of the main contact at the security provider. This is TMHCC signaling again that technical truth should come from the technical owner, not from a broker guess [1].

The net result: renewal is not a light-touch exercise. It's a structured re-underwriting that respects what you've already disclosed but demands current accuracy.

What Changes at Renewal: The Key Differences

While the control framework stays largely consistent, the renewal form introduces meaningful differences in scope, lookback period, and disclosure requirements.

Material Entity Changes and Structural Scope

The renewal form begins with a section titled "Additional Entities / Material Changes," and this is where the biggest renewal distinction appears. TMHCC explicitly asks whether [1]:

• Any subsidiaries, affiliated companies, or entities were acquired in the past 12 months
• The insured's legal name changed
• Any merger or consolidation took place during the policy period
• Any new business lines or revenue streams were added

This is a critical renewal difference. A cyber renewal is not just about last year's controls. It's about whether the insured is still the same risk from a structural perspective. If your client acquired a subsidiary, spun off a division, changed legal entity status, or materially altered its footprint, the renewal underwriting has to reflect that new exposure. An acquisition, in particular, introduces new data systems, new vendor relationships, new staff with different access patterns, and potentially new compliance obligations.

Practical implication: Before you submit renewal documentation, confirm with your client whether anything material changed structurally. Document scope creep early so TMHCC doesn't discover it mid-underwriting.

Loss-History Lookback Tightens to 12 Months

The new-business NetGuard Plus form asks about cyber events and related issues over the past three years. The renewal form tightens this lookback to the past 12 months [1]. That sounds like a relief—fewer years to disclose—but it's actually a sharper filter because it forces granular recent-event accuracy.

TMHCC renewal underwriters are particularly interested in this 12-month window because it represents the actual loss experience under the current policy term. They ask explicitly about [1]:

• Complaints or demands involving privacy or network security
• Regulatory investigations, inquiries, or enforcement actions
• Customer notifications of security or privacy breaches
• Cyber extortion demands or ransom requests
• Outages exceeding four hours in duration
• Cyber-caused property damage or business interruption losses
• Losses due to wire-transfer fraud, telecom fraud, or phishing fraud
• Any incidents or breaches discovered during the policy period

If your client had an incident 18 months ago (before this renewal period), it wouldn't appear on the renewal form. But if they had an incident 11 months ago, it absolutely will. And if the incident was discovered during the current policy term but relates to actions in a prior period, it still needs to be disclosed.

Practical implication: As soon as your client receives the renewal notice, pull a 12-month incident log. Don't rely on memory or scattered incident reports. Work with the IT team, security vendor, and finance team to build a clean incident register. This prevents mid-application corrections.

Vendor Dependency Gets More Pointed at Renewal

The new-business form asks for the top 3 most critical vendors. The renewal form keeps that question but adds specificity [1]: whether any IT service provider your client relies on suffered an unscheduled outage or interruption lasting longer than four hours in the prior 12 months, and whether the client's business was interrupted as a result.

This is not abstract risk management language. This is TMHCC saying: "Tell us about the specific vendor outages that actually hit your business in the past year." It signals that vendor dependency gets sharper at renewal because the carrier now has a policyholder history plus a year of evolving vendor reliance to consider.

Practical implication: Document any service outages from critical vendors (MSP, cloud provider, SaaS platform, payment processor, telecom carrier) that lasted more than four hours and affected your client's operations. This includes incidents where your vendor was compromised, updated systems, or had infrastructure failures. If your client depends on a single MSP or cloud provider and that provider had a significant incident, renewal underwriting will ask pointed questions about alternative arrangements and backup plans.

Incident Reporting and Notification Obligation

The renewal form explicitly asks whether your client notified TMHCC of all incidents, losses, claims, suits, or demands received in the past 12 months [1]. This is a practical continuity check that many brokers overlook.

Here's what this means: if your client experienced a security incident during the policy period and did not report it to TMHCC (either because they didn't think it was "big enough" or because the incident response was handled internally), the renewal disclosure requirement flushes that out. Failure to have reported during the policy term, followed by disclosure at renewal, creates underwriting friction and can raise questions about whether the incident was material and whether claims will be honored for similar future incidents.

Practical implication: Establish a clear incident reporting protocol with your client. Create a simple trigger: any security incident, attempted breach, phishing attack with successful credential harvest, unauthorized access, or data exposure—no matter how small—gets reported to the broker and to the carrier immediately, not held until renewal. This prevents the "surprise disclosure" problem at renewal.

Scan Consent Remains Standard

Both the public new-business and renewal NetGuard Plus forms include consent allowing TMHCC to conduct non-intrusive scans of internet-facing systems and applications for common vulnerabilities [1]. At renewal, this isn't new—but it's worth treating as a pre-renewal action item rather than a carrier initiative.

The best renewal strategy is not to wait until the renewal form arrives and then scramble to defend your public footprint. The better move is to reconcile what the public footprint looks like before renewal arrives, then line up the inside-out evidence behind it. Tokio's own paperwork supports that workflow [1].

Where NetGuard Plus Renewals Get Messy: Common Failures

The most common renewal failures fall into predictable patterns.

Failure #1: Structural Changes Are Not Disclosed Upfront

Acquisitions, mergers, renamed entities, new legal structures, and spinoffs all materially change the risk profile. Many brokers don't ask the right upfront question: "Has the company's legal structure, entity scope, or business lines changed since the policy was issued?" The result is that TMHCC discovers the change partway through underwriting and asks for updated financials, new entity documentation, and separate risk profiles for acquired businesses. This delays renewal by 2-3 weeks minimum.

Prevention: Before you request renewal documentation, confirm structural scope with the CFO or risk manager. If there were acquisitions or mergers, get the details early: names, revenues, business lines, IT environments, and integration status.

Failure #2: Stale Evidence for Supposedly Unchanged Controls

An organization may still have MFA, backups, EDR, and phishing training at renewal, but if the evidence is from last year's stack, the renewal application is built on outdated truth. Email platforms migrate (Office 365 version changes, consent/authentication flows evolve). Backup solutions get swapped. MSPs change. Endpoint management tools upgrade. If evidence is stale or tied to a prior year's configuration, the broker is left stitching together answers under deadline pressure.

Prevention: Four weeks before the renewal notice deadline, request refreshed evidence from your client. Don't recycle screenshots or logs from last year. Pull current MFA configuration, current EDR deployment status, current backup architecture, and current vendor relationships. Treat renewal evidence gathering like a new application, even if the controls themselves haven't changed.

Failure #3: Vendor Dependency Is Not Reconciled Coherently

The renewal form asks for top critical vendors and asks about service-provider outages. If the account is heavily dependent on one MSP, cloud provider, payment platform, or software vendor, that dependency should be described coherently—not discovered mid-application because the underwriter sees a backup provider mentioned in one section and a primary provider mentioned elsewhere.

The problem compounds if a critical vendor had a significant incident during the year. If your client's email provider had an outage, if their MSP was hit with ransomware, if their cloud provider had a major failure, renewal underwriting will ask about impact, mitigation, and future redundancy plans. Having the vendor outage story prepared prevents scrambling at renewal.

Prevention: Build a dependency map before renewal: Who are the top 3 vendors? What critical functions do they provide? Did they have any outages or incidents in the past 12 months? If yes, what was the impact, how long was recovery, and what mitigation is now in place? This takes an afternoon but prevents a week of RFI back-and-forth.

Failure #4: Loss History Is Not Prepared as a Clean Register

Many brokers submit renewal applications with loss history described in general terms ("We had a couple of incidents this year") or from scattered email threads. TMHCC's renewal form asks about specific categories of incidents: privacy complaints, regulatory action, customer notifications, extortion demands, outages, cyber-caused losses, fraud losses.

When the underwriter reads vague loss descriptions and then follows up with an RFI asking for dates, dollar amounts, remediation steps, and incident reports, the broker is left reaching out to the client under time pressure. If the incident happened eight months ago and details are scattered, retrieving the information takes time.

Prevention: Create a simple incident register at the start of the renewal cycle. Columns: Date, Type, Root Cause, Duration, Business Impact, Cost, Response Steps, Remediation. Work with IT, security, and finance to populate it. This register becomes the backbone of your renewal loss-history disclosure.

Failure #5: Incident Notification Gaps Create Underwriting Friction

If your client had an incident during the policy period and did not notify the carrier at the time, but then discloses it at renewal, renewal underwriting will ask: Why wasn't this reported? Was the incident assessment wrong (should it have been reported)? If it should have been reported, does the policy respond?

The issue is not usually malice. It's often organizational fragmentation: IT team handles the incident internally, doesn't notify risk management, and risk management doesn't notify the broker. By renewal, nobody remembers to disclose it.

Prevention: Establish a clear incident reporting protocol at the start of the policy year. Any security event—even ones that appear contained or low-severity—gets reported to the broker, who then notifies the carrier. This prevents the "surprise disclosure" problem at renewal and ensures the carrier's claims team has visibility into the actual loss environment.

Pre-Renewal Preparation: The Broker Checklist

If you want a practical renewal workflow that prevents the failures above, use this order of operations.

Step 1: Reconfirm Entity Scope (Target: 4 weeks before renewal notice)

Before anything else, confirm whether the insured added new entities, subsidiaries, or affiliated companies; changed names; merged; or consolidated. Get details:

• List of any acquired companies or subsidiaries (legal name, revenue, primary business)
• Confirmation that all entities will be included in the renewal coverage
• Any entities that were spun off or disposed of during the policy term
• Any merger or consolidation that changed the legal structure

Document this clearly. If there are new entities, TMHCC will want separate risk profiles for each. Don't let this discovery happen during formal underwriting.

Step 2: Refresh the Public Footprint (Target: 3 weeks before renewal notice)

Review domains, websites, subdomains, and internet-facing services. TMHCC's forms and risk services make it clear that the public footprint matters, and the renewal form includes scan consent.

Use BindLedger's free readiness scan to pull the current baseline: email authentication posture (DMARC, SPF, DKIM), TLS certificate status, exposed subdomains, internet-facing services. Catch public issues before the underwriter's scan does.

Key actions:

• Confirm all active domains are still registered and in use
• Review DNS records for exposed subdomains or test infrastructure
• Check TLS certificate validity and validity dates approaching expiration
• Verify DMARC, SPF, DKIM are configured and enforced
• Document any remediation needed before renewal submission

Step 3: Refresh Identity and Endpoint Evidence (Target: 2.5 weeks before renewal notice)

Do not assume last year's MFA or EDR evidence still reflects the estate. Identity and endpoint management can drift significantly in a year:

• Email platform migrated (new conditional access policies, new MFA flows)
• EDR solution updated or endpoints changed
• Remote access tools changed (new RDP, new VPN, new RMM tools)
• Privileged account policies updated (or not enforced consistently)
• Account lockout settings modified

Pull current evidence:

• Current MFA configuration and enforcement scope (email, remote access, privileged accounts)
• EDR deployment report showing current endpoint coverage (servers, workstations, laptops)
• MFA logs showing current user base and enforcement percentage
• Remote access tool list (VPNs, RDP, RDWeb, RMM solutions in use)
• Privileged account policy (if updated, new version; if not, confirmation that prior version still applies)

Step 4: Revalidate Backup and Recovery Evidence (Target: 2.5 weeks before renewal notice)

Backups are one of the most renewal-sensitive topics because they can appear unchanged while the actual configuration has materially drifted. The form still asks about encryption, immutability, offline or air-gapped separation, MFA for backup access, and restore timing.

Pull current evidence:

• Backup architecture diagram or description (where backups are stored, how they're protected)
• Encryption confirmation (algorithm, key management)
• Immutability configuration or offline separation design
• MFA enforcement for backup system access (internal and external)
• Backup cadence confirmation (actual running schedule, not just planned schedule)
• Last three restore tests: dates, systems restored, time to restore
• Realistic restore timing estimate for widespread ransomware recovery

The restore timing question deserves particular attention. Don't answer "We can restore in 4 hours" if your last restore took 8 hours and you have no recent tests. Be realistic about recovery timeframe based on actual experience.

Step 5: Review Incidents, Vendor Outages, and Reporting History (Target: 2 weeks before renewal notice)

This is the step many brokers skip, to their detriment. Tokio's renewal questions are explicit here. Gather:

• Complete 12-month incident log: date, type, root cause, duration, business impact, cost, response
• Any customer or regulatory notifications issued during the policy period
• Any complaints or demands involving privacy or network security
• Any regulatory investigations, inquiries, or enforcement actions
• Cyber extortion demands or ransom requests
• Outages lasting longer than four hours (from your own infrastructure or critical vendors)
• Any cyber-caused property damage, business interruption, or fraud losses
• Confirmation that all incidents were reported to the carrier during the policy period

For vendor outages specifically:

• List any critical vendor outages (MSP, cloud provider, SaaS platform, telecom, payment processor) lasting more than four hours
• Document whether the outage affected your client's business operations
• Brief description of impact and recovery time

Step 6: Confirm Vendor Dependencies and Service Relationships (Target: 1.5 weeks before renewal notice)

Build your vendor dependency map:

1. Top 3 most critical vendors:

   • Name and service provided
   • How critical to business (essential, important, helpful)
   • Domains or web properties associated with vendor
   • Contract renewal date and any service level changes

2. MSP or outsourced security provider:

   • If security is outsourced, confirm the MSP's contact for renewal application
   • Ensure the MSP is prepared to provide evidence on MFA, EDR, patching, backups
   • If there's a backup vendor or redundant provider, document that relationship

3. Recent service incidents:

   • Any vendor outages in the past 12 months lasting more than four hours
   • Impact to your client's operations
   • Recovery actions taken and mitigation implemented

Step 7: Prepare the Incident Notification Confirmation

Work with your client to confirm that all incidents during the policy period were reported to TMHCC and documented. If there's any incident that was NOT reported during the policy year, prepare a clear explanation of why:

• Was it considered too minor to report?
• Was it contained so quickly that reporting seemed unnecessary?
• Was there a reporting process breakdown?

Bringing this up proactively at renewal is better than having TMHCC discover it mid-underwriting.

Step 8: Request Updated Financial Statements (Target: 1 week before renewal notice)

TMHCC uses revenue tier to determine appetite. Request current financial statements or at minimum:

• Year-to-date revenue for current fiscal year
• Projected full-year revenue
• Any significant revenue changes (growth, contraction, acquisition, divestiture)

If revenue has grown above a tier threshold, renewal terms may expand. If it has shrunk, appetite may tighten.

The Pre-Renewal Evidence Packet Template

When you're ready to gather evidence, organize it in this structure:

1. Entity & Scope

• Organizational chart (if changed since new business)
• List of all entities included in renewal (with confirmation of coverage scope)
• Any new subsidiaries or acquired companies (separate evidence packets)

2. Public Footprint

• Domain inventory (all active domains/websites)
• BindLedger readiness scan output (DMARC, SPF, DKIM, TLS status)
• Any internet-facing services or subdomains exposed
• Remediation actions for any public vulnerabilities

3. Identity & Access

• MFA configuration report (email, remote access, privileged accounts)
• Current MFA enforcement scope and percentage of user base
• List of remote access tools in use (VPN, RDP, RDWeb, RMM)
• Privileged account policy (current version)
• Account lockout policy confirmation

4. Endpoint Security

• Current EDR deployment report (100% coverage confirmation)
• NGAV solution list and endpoint coverage
• Last endpoint inventory audit date

5. Backup & Recovery

• Backup architecture diagram or technical description
• Encryption and immutability confirmation
• MFA enforcement for backup access
• Last three restore test logs (dates, scope, duration)
• Realistic recovery time estimate

6. Training & Controls

• Phishing training participation logs (past 12 months)
• Phishing test results (click rates, remediation)
• Wire-transfer verification procedures (documented policy)
• Evidence of wire-transfer verification enforcement (sample email chains or call logs)

7. Incidents & Losses

• 12-month incident register (date, type, impact, response, cost)
• Customer notifications issued during policy period
• Regulatory action or investigation details
• Vendor outage log (incidents affecting operations)
• Confirmation that incidents were reported to carrier

8. Vendor Dependencies

• Top 3 critical vendors (name, service, domains, contact)
• MSP contact information (if security is outsourced)
• Backup/redundant provider relationships
• Recent vendor outages and impact

9. Financial

• Current financial statements or YTD revenue projection
• Confirmation of revenue tier (if changed)

10. Compliance & Certifications

• Any current certifications (SOC 2, ISO 27001, PCI-DSS, etc.)
• Updated compliance status (if changed since new business)
• Any regulatory investigations or audit findings

Organizing evidence this way prevents last-minute scrambling and ensures TMHCC has what they need immediately.

FAQ: NetGuard Plus Renewal

Q1: If my client hasn't had any incidents in the past 12 months, do they need to say anything about loss history?

Yes. TMHCC's renewal form explicitly asks whether incidents, losses, claims, suits, or demands were received. If there were none, answer "No" to loss-history questions. But confirm that answer is accurate. Many organizations have small incidents (a phishing email that was caught, a brief unavailability, a minor unauthorized access) that get dismissed as "not real incidents." Be clear about what constitutes a reportable incident under the policy. When in doubt, disclose.

Q2: Our MSP manages all of our IT security, including EDR and backups. Do I need to get them involved in the renewal?

Absolutely. TMHCC's renewal form asks who is responsible for network security and whether it's internal or outsourced. If it's outsourced, the MSP needs to be the source of technical evidence on MFA, EDR, backups, and patching. Don't try to provide that evidence as a broker. Bring the MSP into the renewal conversation early and ask them to prepare technical evidence responses. This prevents the "broker has incomplete or outdated information" problem that delays underwriting.

Q3: We acquired a company during the policy year. How does that affect renewal?

Acquisitions materially change the risk profile. TMHCC will want separate details on the acquired company: legal name, revenue, business line, IT environment, controls posture, and whether they're being included in the NetGuard Plus renewal or getting separate coverage. Get the acquisition details into the renewal application early. Don't wait for TMHCC to ask. If the acquired company has a different security posture than the parent, that difference affects renewal pricing and terms.

Q4: Does TMHCC renew policies with pending claims?

Yes, but pending claims affect renewal terms and pricing. If your client has a cyber claim actively being adjusted or disputed at renewal time, TMHCC will quote the renewal but the claim will impact pricing and may add exclusions. Sometimes it's better to wait 30-60 days for the claim to close or settle before requesting renewal quotes, so pricing reflects the actual loss, not worst-case reserves. Discuss the timing with TMHCC's underwriting team.

Q5: Can we get a renewal quote before the policy expires?

Yes, and in fact it's recommended. Start renewal conversations 90 days before expiration. This gives you time to gather evidence, address any gaps, and secure renewal terms before your client is at risk of lapse. TMHCC's renewal forms are typically available 90 days before expiration, so use that window to get the evidence packet assembled.

Q6: What if our client's IT environment changed materially during the policy year (migrated to a new cloud platform, changed backup vendors, deployed new EDR)?

Material changes to IT environment don't necessarily stop renewal, but they need to be clearly described. TMHCC sees the renewal form as a checkup on the current risk, so if the environment changed significantly, the renewal evidence should reflect the new reality. For example, if your client migrated from on-premises servers to AWS during the year, the backup evidence should show current AWS backup architecture, not the old on-premises approach. Describe the migration and timing, and explain whether the new environment is materially more or less secure than what was in place at new business.

Q7: Our client has a renewal form with a deadline coming up fast. How much time do we need to respond?

TMHCC typically gives 45-60 days for renewal submissions. That seems like a lot, but once you factor in evidence gathering (2-3 weeks), broker review (1 week), and TMHCC underwriting (2-3 weeks), you're right up against the deadline. Don't wait until 14 days before expiration to start gathering evidence. If renewal is coming due, pull the trigger on evidence requests immediately.

Common Renewal Mistakes to Avoid

Mistake #1: Treating renewal like a box-checking exercise. Renewal is a re-underwriting. Answer each question with current, accurate information. Don't recycle last year's responses.

Mistake #2: Assuming EDR, MFA, and backups are "still there." They might be, but the configuration, deployment scope, or implementation may have changed. Refresh evidence.

Mistake #3: Not preparing incident history early. Don't assemble incident details the week before renewal is due. Start pulling incident logs immediately, while memory is fresh and documentation is findable.

Mistake #4: Letting vendor dependency be discovered by TMHCC. If your client depends heavily on a single MSP, cloud provider, or payment processor, be upfront about it. TMHCC will ask about outages and mitigation anyway.

Mistake #5: Not involving the technical owner in renewal. If IT is outsourced, the MSP needs to be part of the renewal conversation. Don't try to proxy technical answers.

Mistake #6: Omitting small incidents because they seem insignificant. TMHCC's renewal form asks about complaints, demands, breaches, outages, and fraud. Small incidents count. Disclose rather than guess whether something is reportable.

Mistake #7: Waiting until renewal notice arrives to assess public footprint. Run a scan before renewal comes due so you can remediate any public vulnerabilities or configuration gaps on your own timeline, not TMHCC's.

Renewal Readiness Tools and Resources

Before you submit a NetGuard Plus renewal, use these tools to validate your client's readiness:

BindLedger's Free Readiness Scan: Run this first. It validates your client's public footprint (domains, email authentication, TLS status, exposed subdomains) in about 10 minutes. Catch public vulnerabilities before TMHCC's scan does.

Carrier Decoder: Once you have your client's responses and evidence, use the Carrier Decoder to organize everything by TMHCC's specific renewal requirements. This tool extracts policy language and maps your evidence to what the form actually tests.

How to Prove Backup Immutability: TMHCC renewal forms ask for specific backup evidence. This guide shows you how to document encryption, immutability, offline separation, MFA access control, and restore timing in the language TMHCC expects.

The M365 MFA Reporting Gap: If your client uses Microsoft 365 (which most do), this guide shows how to pull MFA enforcement reports that meet TMHCC's standards. Renewal underwriters will ask for MFA proof; know how to generate it correctly.

The Complete Guide to Cyber Insurance Evidence in 2026: For a comprehensive overview of documentation TMHCC and other carriers ask for at renewal, review this guide. It covers incident history, financial evidence, compliance documentation, and everything in between.

The Bottom Line: Renewal Is Its Own Event

NetGuard Plus renewal is not new business simplified. It's a structured re-underwriting that respects your prior disclosure but demands current accuracy. TMHCC's renewal form keeps the same control families in view (MFA, EDR, backups, phishing, vendors, security ownership) but tightens the loss-history lookback to 12 months and adds sharper questions about entity scope, vendor outages, and incident notification.

The brokers who have the smoothest renewals follow a simple pattern: they confirm scope early, refresh evidence from current systems, reconcile vendor dependencies, and build a clean incident register. They don't wait until renewal arrives under deadline pressure to figure out what changed or what needs to be documented.

Start renewal preparation 60-90 days before your client's policy expiration. Pull the pre-renewal checklist. Use BindLedger's readiness scan to validate the public footprint. Request refreshed evidence from the technical team. And involve the network security owner—whether internal or outsourced—directly in the renewal process.

When the form arrives, you'll be ready. When TMHCC asks for clarification, you'll have the answer. And when renewal terms are issued, you'll likely see favorable continuity because you've demonstrated that your client's security posture is current, accurate, and genuinely managed.

---