Incident Response

Security incidents can happen to any organization. What matters is how quickly and effectively they are detected, contained, and resolved. BttrForm maintains a structured incident response process designed to minimize impact and keep you informed every step of the way.

Incident Classification

BttrForm classifies security incidents into four severity levels. The severity determines the response timeline, escalation path, and communication approach.

Detection

BttrForm employs multiple layers of monitoring to detect security incidents as early as possible.

Automated Monitoring

• Infrastructure monitoring -- CPU, memory, disk, and network metrics tracked in real time. Anomalous spikes trigger alerts.
• Application error tracking -- Runtime errors and exceptions are captured and aggregated. Unusual error patterns generate alerts.
• Authentication monitoring -- Failed login attempts, impossible travel (logins from geographically distant locations in short timeframes), and credential stuffing patterns are detected automatically.
• API rate anomalies -- Sudden spikes in API traffic or unusual request patterns are flagged for review.

Audit Logs

All security-relevant actions are logged in the audit system:

• Authentication events (login, logout, password changes)
• Data access events (exports, downloads, bulk operations)
• Configuration changes (permissions, security settings, integrations)
• Administrative actions (user management, billing changes)

Audit logs are immutable and retained for a minimum of 365 days. See the audit logging documentation for details on retention policies.

Anomaly Detection

BttrForm uses baseline behavioral analysis to detect unusual patterns:

• Data exfiltration signals -- Unusually large exports, rapid sequential downloads, or bulk API reads outside normal patterns.
• Access pattern changes -- Users accessing resources they have never accessed before, or accessing data at unusual times.
• Geographic anomalies -- Access from countries or IP ranges not associated with the organization's normal activity.

Triage Process

When a potential incident is detected, the on-call security team initiates the triage process.

Initial Assessment

1. Confirm the incident -- Verify that the alert represents a genuine security event, not a false positive.
2. Classify severity -- Assign an initial P1--P4 severity based on the classification table above.
3. Identify scope -- Determine which systems, data, and customers are potentially affected.
4. Assign incident commander -- A senior engineer takes ownership of the incident and coordinates the response.

Impact Evaluation

The incident commander evaluates:

• Data impact -- Was data accessed, modified, or exfiltrated? What type of data (PII, PHI, financial)?
• System impact -- Which services are affected? Is the platform operational?
• Customer impact -- How many customers are affected? Are they aware?
• Regulatory impact -- Does this trigger mandatory breach notification under GDPR, HIPAA, or other regulations?

Notification Timeline

BttrForm follows strict notification timelines that meet or exceed regulatory requirements.

Customer Notification Process

For confirmed incidents that affect customer data:

1. Initial notification (within 24 hours) -- Email and dashboard notification confirming the incident, known scope, and immediate actions taken.
2. Progress update (within 48 hours) -- Additional details on root cause, affected data, and remediation status.
3. Resolution notification -- Final communication confirming the incident is resolved, full scope of impact, and preventive measures implemented.

Containment

The goal of containment is to stop the incident from spreading while preserving evidence for investigation.

Immediate Containment Actions

Depending on the incident type, containment may include:

• Revoking compromised credentials -- API keys, session tokens, or passwords identified as compromised are invalidated immediately.
• Isolating affected systems -- Network-level isolation of compromised servers or services to prevent lateral movement.
• Blocking malicious IPs -- Firewall rules updated to block identified attacker IP addresses or ranges.
• Disabling compromised accounts -- User accounts showing signs of unauthorized access are suspended pending investigation.
• Rate limiting -- Aggressive rate limiting applied to affected endpoints to slow down ongoing attacks.

Evidence Preservation

Before any remediation that might alter system state:

• Forensic snapshots of affected systems are captured.
• Audit logs are exported and archived to immutable storage.
• Network traffic logs are preserved.
• Application logs for the affected time period are secured.

Remediation

Once the incident is contained, the team focuses on identifying and fixing the root cause.

Remediation Steps

1. Root cause analysis -- Identify the vulnerability, misconfiguration, or attack vector that enabled the incident.
2. Develop fix -- Engineer and test a fix for the root cause. For critical incidents, a hotfix is deployed within hours.
3. Verify fix -- Confirm the fix addresses the root cause and does not introduce new issues. This includes regression testing and security review.
4. Deploy fix -- Roll out the fix to production. For P1/P2 incidents, this may involve out-of-band deployments.
5. Confirm resolution -- Monitor systems to verify the incident is fully resolved and no recurrence is observed.

Post-Mortem

Every P1 and P2 incident receives a formal post-mortem. P3 incidents receive post-mortems at the discretion of the security team.

Post-Mortem Template

BttrForm post-mortems follow a structured format:

Incident Post-Mortem: [Incident Title]
Date: [Date of incident]
Severity: [P1/P2/P3/P4]
Duration: [Start time -- Resolution time]
Incident Commander: [Name]

1. Summary
   Brief description of what happened.

2. Timeline
   Chronological sequence of events from detection to resolution.

3. Impact
   - Systems affected
   - Data affected (type and volume)
   - Customers affected (count and segments)
   - Duration of impact

4. Root Cause
   Technical description of the underlying cause.

5. Contributing Factors
   Other factors that enabled or worsened the incident.

6. Resolution
   Steps taken to resolve the incident.

7. Action Items
   - [Action] -- [Owner] -- [Due Date]
   - [Action] -- [Owner] -- [Due Date]

8. Lessons Learned
   What we will do differently going forward.

Post-Mortem Principles

• Blameless -- Post-mortems focus on systems and processes, not individuals. The goal is to prevent recurrence, not assign blame.
• Thorough -- Every contributing factor is documented, even if it seems minor.
• Actionable -- Every post-mortem produces specific action items with owners and deadlines.
• Shared -- Relevant findings are shared with affected customers (with sensitive technical details redacted as appropriate).

Communication

How We Notify Affected Customers

• Email -- Direct notification to the account owner and all organization admins.
• Dashboard notification -- A banner in the BttrForm dashboard with incident details and status.
• Status page -- Public updates on our status page for incidents affecting platform availability.

What We Include in Notifications

• Description of the incident
• What data was potentially affected
• What actions BttrForm has taken
• What actions you should take (e.g., rotate API keys, review access logs)
• Point of contact for questions

Requesting Incident Information

If you believe your data may have been affected by a security incident, or if you need additional details about a past incident, contact our security team at security@bttrlabs.com. Include your organization name and the nature of your concern.