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
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 GET https://api.neostra.io/v1/breach-types \
-H "Authorization: Bearer <token>"
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"
}'
curl -X DELETE https://api.neostra.io/v1/breach-types/{typeId} \
-H "Authorization: Bearer <token>"
| 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 GET https://api.neostra.io/v1/breach-incidents \
-H "Authorization: Bearer <token>"
curl -X GET https://api.neostra.io/v1/breach-incidents/{incidentId} \
-H "Authorization: Bearer <token>"
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
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 |
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
Last updated 1 week ago
Built with Documentation.AI