Security

Incident Response Plan

How Oceum detects, responds to, and recovers from security incidents.

1. Incident Classification

All security incidents are classified by severity to determine response urgency, communication requirements, and escalation paths.

Severity	Description	Response Time	Examples
Critical (P1)	Active data breach, service-wide outage, credential compromise	15 minutes	Unauthorized database access, vault key compromise, production down
High (P2)	Partial outage, single-org data exposure, authentication bypass	1 hour	Single endpoint failure, RLS bypass, failed login spike
Medium (P3)	Degraded performance, non-critical vulnerability discovered	4 hours	Elevated error rates, dependency CVE, agent drift
Low (P4)	Minor issue, informational finding	24 hours	Configuration drift, stale dependency, documentation gap

2. Detection

Oceum employs multiple layers of automated and continuous monitoring to detect security incidents as early as possible.

Security agent runs automated security audits daily, performing 8 checks: failed login anomalies, error rate spikes, stale agent detection, vault access anomalies, data isolation verification, security header validation, dependency freshness, and rate limit threshold analysis.
Sentry error monitoring with real-time alerting on unhandled exceptions, elevated error rates, and new issue detection across all serverless functions.
Uptime health monitoring runs every 15 minutes, verifying endpoint availability, response latency, database connectivity, and agent heartbeat status.
Login audit trail records IP address, user agent, timestamp, and outcome for every authentication attempt, enabling pattern detection on brute-force and credential-stuffing attacks.
Rate limiting triggers automatically throttle and alert on brute-force patterns, including login attempts, password resets, and API key generation.

3. Response Procedure

When an incident is detected, the following six-step procedure is executed. Steps are sequential but may overlap during active response.

Identify. Confirm the incident is genuine. Security or Sentry alert triggers initial review. Examine application logs, error traces, and access patterns. Determine severity level per the classification table above. Assign an incident owner.
Contain. Isolate affected systems to prevent further damage. Revoke tokens for compromised accounts. Pause affected agents via the governance layer. Rotate any compromised credentials (API keys, vault keys, webhook secrets). If a full service compromise is suspected, enable maintenance mode.
Eradicate. Identify and fix the root cause. Deploy the patch to production via Vercel. Verify the fix resolves the vulnerability without introducing regressions. If a dependency is the root cause, update or replace it immediately.
Recover. Restore normal operations. Verify service health via /api/health and Uptime monitoring. Re-enable any paused agents. Monitor for recurrence over the next 24–72 hours with increased alerting sensitivity.
Notify. Notification is severity-dependent. P1 and P2 incidents: notify affected customers within 72 hours per GDPR Article 33. P1 incidents involving personal data breach: notify the relevant supervisory authority within 72 hours. All notifications include what happened, what data was affected, what we did, and what the customer should do.
Review. Conduct a post-incident review within 5 business days. Document the timeline, root cause, impact, and remediation. Identify lessons learned and update controls, monitoring, or procedures to prevent recurrence. Publish an internal post-mortem.

4. Communication Channels

Internal communication during an active incident uses the following channels:

Telegram alerts — Security delivers automated findings to @oceum_bot. Critical findings trigger immediate notification to the incident response team.
Sentry — real-time error tracking with issue assignment, status tracking, and regression detection.
Email — used for incident coordination when Telegram is unavailable and for post-incident review distribution.

External communication during and after an incident:

security@oceum.ai — primary contact for security reports from external parties and for inbound inquiries during an active incident.
Customer notification — affected customers receive direct email with incident details, impact scope, remediation steps taken, and recommended actions.
Supervisory authority — for P1 breaches involving personal data, notification is filed with the applicable data protection authority within 72 hours per GDPR Article 33.

5. Contacts

Security Lead: jo@oceum.ai
Incident Response: security@oceum.ai
Vulnerability Reports: /.well-known/security.txt

If you discover a security vulnerability in Oceum, please report it responsibly via security@oceum.ai. We will acknowledge receipt within 24 hours and provide an initial assessment within 72 hours.