Report what is known. Mark what is still being checked.
Use this provider security incident notification form for a first notice, update, or closure proposal. Record the facts available now, the actions already taken, the owner, and the next update without waiting for a complete diagnosis.
This is a coordination form, not an incident-response plan, legal opinion, breach determination, or compliance assessment. Follow the applicable contract, incident plan, company policy, and law, and do not submit active incident details through OutsourcedU.
Use one incident reference for the first notice, updates, and closure proposal.
Separate confirmed, estimated, suspected, and unknown details.
Give a date, time, timezone, route, and owner.
Give the client a usable record, not a polished incident essay.
An early notice can contain unknowns. It still needs a clear service scope, current status, named owners, held decisions, and a reliable update time.
Notice and timeline
Start with the notice type, incident reference, affected service, discovery time, and timezone. Keep discovery time separate from the estimated start of the event.
- Initial notice, update, or closure proposal
- Provider incident reference and affected service
- Discovery time, detection source, and timezone
- Earliest known activity time: confirmed, estimated, or unknown
Known facts and open questions
Describe what was observed in plain words. Separate confirmed facts, reported claims, working ideas, and unknowns so the client can see what may change.
- Short factual summary
- Confirmed facts and their source
- Suspected details that are not confirmed
- Important unknowns still being checked
Systems, service, and data
Name the systems, accounts, service functions, locations, and data categories that may be involved. Do not paste live records or sensitive evidence into the notice.
- Provider and client systems or accounts
- Service impact: operating, limited, paused, or unavailable
- Data categories and approximate scope, if known
- Relevant subcontractor or subprocessor
Current access and containment
State whether suspicious access or activity may still continue, with the time last checked. List actions already taken, their owners, and the result observed without claiming full containment too early.
- Current access state and as-of time
- Actions completed, owner, time, and observed result
- Actions in progress and next check
- Action held while approval is pending
Evidence and records
List the records that were preserved and where an approved reviewer can find them. Keep raw logs, secrets, customer records, and exploitable details in the approved restricted location.
- Evidence type and source system
- Date range and preservation time
- Approved storage location or reference
- Evidence owner and known gaps
Owners and required decision
Name the provider lead, client owner, secure contact route, and after-hours backup. Put the exact client decision in its own field instead of hiding it inside the incident story.
- Provider incident lead and backup
- Client incident or system owner
- Exact decision, decision owner, and needed-by time
- Action held and record location while waiting
Next update and closure
Promise a specific next-update time and route even if the investigation will take longer. For closure, record checked conditions, unresolved work, owners, and the final evidence location.
- Next update date, time, timezone, route, and owner
- Events that trigger an earlier update
- Closure conditions and evidence references
- Open corrective actions, owners, and review date
Show what changed from one update to the next.
Northstar Demo is fictional, and the times below do not set a response standard. On smaller screens, scroll the table horizontally to see every field.
| Notice stage | Facts and unknowns | Action and current state | Owner, decision, or next update |
|---|---|---|---|
| Initial notice | Confirmed: one provider account signed in from an unexpected location at 14:12 UTC. Unknown: whether client records were opened or exported. | The identity lead disabled the account at 14:35 UTC. Other sessions and connected tokens remain under review. | Provider incident lead, 16:30 UTC through the approved ticket. |
| Scope update | Confirmed: the account could reach the Northstar Demo reporting folder. No evidence of export was found in the logs checked through 16:00 UTC. | The team revoked active sessions and rotated the service credential. The integration remains paused pending a client decision. | Client system owner decision requested by 17:00 UTC; provider update at 18:00 UTC. |
| Closure proposal | Fictional example only: the named logs show no activity after session revocation. The client owner still needs to review the final evidence reference. | Recovery checks passed for the demo integration. A 14-day monitoring task has an owner and due date. | Provider and client incident owners review closure on 2026-08-05 at 15:00 UTC. |
Send the first useful notice before the final answer exists.
Do not include passwords, keys, recovery codes, live customer records, raw logs, exploit details, or other sensitive evidence. Put sensitive material in the approved secure location and share only its reference here.
PROVIDER SECURITY INCIDENT NOTIFICATION FORM NOTICE DETAILS Notice type: [Initial notice, update, or closure proposal] Provider incident reference: Provider and service affected: Submitted date, time, and timezone: Previous update reference, if any: Approved notice route or ticket: DISCOVERY AND TIMELINE Discovery date, time, and timezone: Detected by: How it was detected: Earliest known activity time: [Confirmed, estimated, or unknown] Provider incident owner notified at: Client first notified at: WHAT IS KNOWN NOW Short factual summary: Confirmed facts and source: Reported or suspected details not yet confirmed: Important unknowns still being checked: SYSTEMS, SERVICE, AND DATA Provider systems, accounts, devices, or locations involved: Client systems or integrations involved: Service status: [Operating, limited, paused, or unavailable] Data categories potentially involved: Approximate scope and basis, if known: Subcontractor or subprocessor involved, if any: Items checked and outside the current known scope: CURRENT ACCESS AND CONTAINMENT Can suspicious access or activity still continue? [Yes, no, or unknown] Status last checked at, including timezone: Actions completed, with owner, time, scope, and observed result: Actions in progress and next check: Action held pending approval: EVIDENCE AND RECORDS Evidence preserved and source system: Relevant date range: Preserved by and time: Approved secure location or evidence reference: Evidence owner and known gaps: OWNERS AND DECISION Provider incident lead, route, timezone, and backup: Client incident or system owner, route, timezone, and backup: Exact client decision or approval requested: Decision owner and needed-by time: Action held while waiting: Where the decision will be recorded: NEXT UPDATE Next update date, time, and timezone: Update route, recipients, and provider owner: What will be checked before then: Events that will trigger an earlier update: CLOSURE RECORD Closure conditions checked and evidence references: Remaining unknowns or accepted residual risk: Open corrective actions, owners, and due dates: Provider closure approver: Client closure approver: Post-incident review date: Final secure record location: Do not include passwords, keys, recovery codes, live customer records, raw logs, exploit details, or other sensitive evidence. Exchange sensitive material only through an approved secure channel. This form supports coordination. It is not an incident-response plan, legal opinion, breach determination, or compliance assessment. Follow the applicable contract, incident plan, company policy, and law.
The full form stays visible and selectable. Nothing is uploaded or saved.
Keep the report moving while the facts change.
Use the written incident route and keep one reference across every update. Qualified security, privacy, legal, insurance, and communications owners decide any required external notice.
- Send the first notice through the approved incident route without waiting for every field to be known.
- Mark each important statement confirmed, estimated, suspected, or unknown, and add an as-of time.
- Keep sensitive evidence in the approved restricted location and put only its reference in the notice.
- Name the action held, the decision owner, and the exact next-update time with timezone.
- Use the same incident reference for updates, then check the agreed closure conditions before closing the record.
Use guidance to prepare the handoff, not to claim compliance.
These sources support incident roles, records, coordination, evidence preservation, and supplier responsibilities. They do not certify this form or create one notice deadline for every contract or jurisdiction.
- NIST SP 800-61 Rev. 3 covers incident responsibilities, information flow, coordination, response records, and third-party roles.
- NIST Cybersecurity Framework 2.0 covers response, recovery, supplier planning, and named cybersecurity responsibilities.
- NIST SP 800-161 Rev. 1 covers supplier incident coordination, contracts, monitoring, and service-end responsibilities.
- FTC, Data Breach Response: A Guide for Business covers securing operations, preserving evidence, and assigning response work.
Review the notification route without sending incident details.
Bring the planned owners, contract terms, channels, and access rules. Do not paste an active incident or sensitive evidence into the contact form.