Cyber losses do not always appear immediately. An attacker can remain in a network for months, a privacy event can be discovered long after the first unauthorized access, and a third party may not make a liability claim until well after the underlying incident. That delay is why policy timing matters almost as much as the limit.
A Chubb small-business cyber sample form illustrates the concept: certain third-party liability agreements apply to a claim first made during the policy period for a cyber incident that first occurs on or after the retroactive date and before the end of the policy period. That is one example, not a universal wording. Cyber policies can use different triggers for different insuring agreements.
Retroactive date vs. policy start date
The policy start date tells you when the current contract begins. The retroactive date can be earlier. If a business has maintained continuous claims-made coverage for years, the insurer may preserve an older retroactive date so covered prior acts remain eligible if a claim is first made later.
| Date | What it means | Why it matters |
|---|---|---|
| Retroactive date | Earliest covered incident/act date for specified claims-made coverage | An incident before this date may be outside coverage |
| Policy effective date | Start of the current policy period | Current terms, limits and retention begin here |
| Claim-made date | When a third party first makes a claim, as defined by the policy | Often must fall within the policy period or valid reporting extension |
| Discovery date | When the insured discovers an incident | Can control first-party cyber benefits under some forms |
Why cyber policies can have more than one timing trigger
A cyber policy can combine first-party and third-party coverage. First-party sections may reimburse breach response, data recovery, business interruption or cyber extortion after a covered incident is discovered during the policy period. Liability sections may be claims-made, meaning the third-party claim must be made during the policy period. The same policy can therefore contain more than one important date.
Do not use a single summary such as “claims-made policy” to assume every insuring agreement behaves identically. Read the trigger language for network security liability, privacy liability, media liability, regulatory coverage, business interruption, extortion and other sections separately.
A simple retroactive-date example
A company first buys cyber liability coverage effective January 1, 2024, with a January 1, 2024 retroactive date. A hacker gains unauthorized access in June 2024, but the company does not discover the issue until February 2026. A customer then makes a privacy claim in March 2026.
If the company renewed continuously and the liability coverage still recognizes January 1, 2024 as the retroactive date, the old incident may be within the eligible prior-acts period, subject to all other terms. If the company switched insurers in 2026 and accepted a new January 1, 2026 retroactive date, the June 2024 incident could fall before the coverage boundary.
Prior knowledge is a separate issue
Preserving a retroactive date does not erase known circumstances. Cyber applications commonly ask about known incidents, events or facts that could lead to a claim. Policies can exclude matters that were known before inception, and inaccurate application answers can create additional problems. Report known circumstances promptly under the existing policy when the wording permits or requires it.
What to check when switching cyber insurers
- Match the retroactive date. Do not assume the new insurer will automatically preserve it.
- Compare definitions of claim and cyber incident. Small wording changes can alter the trigger.
- Review pending and prior matters. Disclose known incidents and circumstances accurately.
- Check continuity clauses. Some forms preserve treatment of prior disclosures or prior acts under specific conditions.
- Review extended reporting options. A tail can preserve reporting rights for certain claims after a claims-made policy ends, but it normally does not insure new incidents occurring after termination.
- Map first-party vs. liability triggers. Discovery-based business interruption can operate differently from claims-made liability.
Retroactive date vs. extended reporting period
These concepts solve different problems. The retroactive date reaches backward to define how old an eligible underlying act or incident may be. An extended reporting period reaches forward by allowing certain claims arising from covered prior acts to be reported after a claims-made policy ends. It usually does not move the retroactive date or create coverage for incidents that happen during the tail.
Frequently asked questions
Does every cyber policy have a retroactive date?
No. Policy structures vary. Some insuring agreements use claims-made timing and a retroactive date, while other first-party benefits may be triggered by discovery or occurrence language.
Can I change insurers without losing prior-acts coverage?
Often yes, if the new policy preserves an appropriate retroactive date and the transition satisfies its continuity and prior-knowledge terms. Confirm this in writing before binding.
Is a retroactive date the same as a waiting period?
No. A waiting period usually refers to time before a benefit begins, such as a business interruption waiting period. A retroactive date is a boundary for when the underlying act or incident must have occurred.
Sources & further reading
Reviewed against public cyber policy wording on October 5, 2026. Cyber forms are not standardized; the issued policy and endorsements control.
