Breach Management

Incident reporting, configurable intake forms, and breach response workflows

Overview

Neostra's Breach Management module provides a structured approach to handling data breach incidents from initial reporting through resolution. It includes configurable intake forms, incident classification by breach type, and workflow-driven response processes powered by the same workflow engine used for DSAR handling.

Intake Forms

Design and publish configurable breach intake forms with versioning support for consistent incident reporting.

Breach Types

Classify incidents by configurable breach type categories for consistent tracking and reporting.

Workflows

Automate breach response with multi-stage workflows, task assignments, and SLA tracking.

Incidents

Track breach incidents from intake through resolution with full audit trail.

Breach Response Workflow

Breach incidents move through configurable workflow stages powered by the same engine used for DSAR management. Each stage can include assigned tasks, approvals, and notifications.

Breach workflows are fully configurable. The stages shown above represent a typical configuration. Your organization can customize stages, transitions, and task assignments to match internal incident response procedures.

Intake Forms

Breach intake forms define the structure for incident reporting. Forms support versioning with a publish lifecycle so you can iterate on form design without affecting active incidents.

Create an Intake Form

Define a new breach intake form with configurable fields.

curl -X POST https://api.neostra.io/v1/breach-intake-forms \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Standard Breach Report Form",
    "description": "Default intake form for all breach incidents"
  }'

Configure Form Fields

Add fields to the form to capture the information needed for initial triage.

curl -X PUT https://api.neostra.io/v1/breach-intake-forms/{formId}/fields \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "fields": [
      {
        "label": "Incident Date",
        "type": "DATE",
        "required": true
      },
      {
        "label": "Description of Incident",
        "type": "TEXTAREA",
        "required": true
      },
      {
        "label": "Estimated Number of Affected Individuals",
        "type": "NUMBER",
        "required": false
      },
      {
        "label": "Data Categories Involved",
        "type": "MULTI_SELECT",
        "options": ["Personal", "Financial", "Health", "Biometric", "Children"],
        "required": true
      },
      {
        "label": "Breach Type",
        "type": "BREACH_TYPE_SELECT",
        "required": true
      }
    ]
  }'

Publish the Form

Publish the form to make it available for incident reporting.

curl -X POST https://api.neostra.io/v1/breach-intake-forms/{formId}/publish \
  -H "Authorization: Bearer <token>"

Form Versioning

Intake forms use a version-based lifecycle:

Draft: Form is being edited and is not available for incident submission.
Published: Form is active and used for new breach reports. Only one version can be published at a time.
Archived: Previous versions are retained for reference. Existing incidents continue to reference the form version that was active at the time of their creation.

When you need to update a published form, create a new version in draft, make your changes, and publish. The previous version is automatically archived.

Breach Types

Breach types provide a classification system for categorizing incidents. Configure types to match your organization's incident taxonomy.

curl -X POST https://api.neostra.io/v1/breach-types \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Unauthorized Access",
    "description": "Unauthorized individual gained access to personal data"
  }'

curl -X PUT https://api.neostra.io/v1/breach-types/{typeId} \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Unauthorized Access",
    "description": "Updated description for unauthorized access incidents"
  }'

Breach Type	Description
Unauthorized Access	An unauthorized party accessed personal data
Data Theft	Personal data was intentionally stolen
Accidental Disclosure	Personal data was unintentionally exposed
Ransomware	Systems containing personal data were encrypted by malware
Lost Device	A device containing personal data was lost or stolen
Phishing	Personal data was obtained through social engineering
System Misconfiguration	Data exposed due to incorrect system settings

Breach Incidents

Incidents are created when a breach intake form is submitted and then move through the configured workflow stages.

curl -X POST https://api.neostra.io/v1/breach-incidents \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "formId": "form_001",
    "breachTypeId": "type_unauthorized_access",
    "responses": {
      "incident_date": "2026-03-10",
      "description": "Unauthorized access to customer database detected via anomalous query patterns.",
      "estimated_affected": 1500,
      "data_categories": ["Personal", "Financial"]
    }
  }'

curl -X POST https://api.neostra.io/v1/breach-incidents/{incidentId}/transitions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "targetStage": "INVESTIGATING",
    "notes": "Investigation team assigned. Initial review indicates SQL injection vector."
  }'

Key API Endpoints

Method	Endpoint	Description
`POST`	`/breach-intake-forms`	Create a new intake form
`GET`	`/breach-intake-forms`	List all intake forms
`GET`	`/breach-intake-forms/{id}`	Get intake form details
`PUT`	`/breach-intake-forms/{id}`	Update an intake form
`DELETE`	`/breach-intake-forms/{id}`	Delete an intake form
`POST`	`/breach-intake-forms/{id}/publish`	Publish an intake form
`POST`	`/breach-types`	Create a breach type
`GET`	`/breach-types`	List all breach types
`PUT`	`/breach-types/{id}`	Update a breach type
`DELETE`	`/breach-types/{id}`	Delete a breach type
`POST`	`/breach-incidents`	Submit a new breach incident
`GET`	`/breach-incidents`	List breach incidents
`GET`	`/breach-incidents/{id}`	Get incident details
`POST`	`/breach-incidents/{id}/transitions`	Advance workflow stage

Permissions

Resource	Permissions
Breach Intake Forms	`breach-forms:create`, `breach-forms:view`, `breach-forms:list`, `breach-forms:edit`, `breach-forms:delete`
Breach Types	`breach-types:create`, `breach-types:list`, `breach-types:edit`, `breach-types:delete`

Deleting a breach type that is referenced by existing incidents will fail. Reassign or close associated incidents before removing a breach type.

Integration with Workflow Engine

Breach Management uses the same workflow engine that powers DSAR (Data Subject Access Request) handling. This shared engine provides:

Configurable stages: Define the stages a breach incident passes through from intake to closure.
Task assignments: Assign tasks to specific users or teams at each stage.
SLA tracking: Set time-based SLAs for each stage to ensure timely breach response.
Notifications: Trigger email and in-app notifications on stage transitions.
Audit trail: Every stage transition, task completion, and comment is logged to the Evidence Vault.

Workflow configurations for breach management are independent from DSAR workflows, allowing each process to have its own stages and rules while benefiting from the same underlying engine.

Regulatory Notification Timelines

When a breach meets regulatory thresholds, organizations must comply with jurisdiction-specific notification requirements. Neostra automatically calculates applicable timelines based on the geographic scope of the breach.

Regulation	Authority Notification	Data Subject Notification	Notes
DPDPA (India)	As prescribed by the Board	As prescribed by the Board	Notify the Data Protection Board of India and affected Data Principals
GDPR (EU)	72 hours from awareness	Without undue delay if high risk	Notify the Supervisory Authority; data subjects only if high risk to rights
CCPA/CPRA (US-CA)	N/A (no authority notification)	"In the most expedient time possible"	Notification required if unencrypted personal information is breached

Regulatory timelines start from the moment the organization becomes aware of the breach, not from the date the breach occurred. Accurate recording of the "Date Discovered" field in the intake form is critical for compliance.

Severity Scoring

Neostra uses a severity scoring mechanism to classify breach incidents and determine appropriate response timelines. Scores are generated based on the category of personal data involved in the breach.

Severity Level	Score Range	SLA: Initial Assessment	SLA: Escalation to DP Lead	Example Data Categories
Critical	90-100	4 hours	Immediate	Biometric, children's data, financial credentials
High	70-89	12 hours	24 hours	Health records, government IDs (Aadhaar, PAN, SSN)
Medium	40-69	24 hours	48 hours	Contact details, purchase history, employment data
Low	0-39	48 hours	5 business days	Publicly available information, anonymized datasets

Data category sensitivity: Higher scores for special category data (biometric, health, financial, children's)
Volume of affected individuals: Score increases proportionally with the number of affected data subjects
Data exposure type: Active exfiltration scores higher than accidental disclosure
Encryption status: Encrypted data at rest reduces the score
Geographic scope: Multi-jurisdiction breaches score higher due to compound regulatory obligations

Stakeholder Notification

When a breach is created, Neostra automatically identifies required stakeholders and generates notification tasks within the breach workflow.

Identify Applicable Jurisdictions

Based on the geographic location of affected data subjects, Neostra determines which regulatory frameworks apply (DPDPA, GDPR, CCPA, etc.).

Generate Notification Tasks

The system creates notification tasks for each required stakeholder: the Data Protection Board (DPDPA), Supervisory Authority (GDPR), affected Data Subjects, and the organization's Data Fiduciary / Executive Sponsor.

Send Notifications

Notification tasks include pre-configured email templates with the required regulatory information. Templates are customizable per regulation and include: breach description, data categories involved, estimated number of affected individuals, measures taken, and contact details for the Grievance Officer or DPO.

Track Acknowledgement

All notifications are tracked with delivery status, acknowledgement timestamps, and any responses received.

Breach Terminology Reference

Term	Definition
Date Discovered	The date and time the incident was first discovered by the organization
Date Occurred	The date and time the incident actually took place
Date Reported	The date and time the incident was formally reported in the system
DINA (Dynamic Incident Notification Assessment)	The engine that determines which regulatory notifications are required based on breach characteristics, jurisdiction, and severity
Databreachpedia	A built-in database of global data breach regulations integrated into the Incident Management module, providing notification requirements, timelines, and contact details per jurisdiction
Incident Register	The central repository documenting individual incident details, stage progression, assessments, subtasks, jurisdictions, attachments, and activities
Incident Web Forms	Configurable intake forms that define data collection parameters for specific incident types, embeddable in internal portals

Was this page helpful?

Last updated Mar 18, 2026

Built with Documentation.AI