This page explains how Shipber manages security incidents end to end. It is informational. Contractual commitments are set out in the Shipber Services Agreement and the Data Processing Addendum (DPA).
Our approach
We recognize that security incidents can occur. Shipber operates a defined incident response program designed to detect, contain, and remediate events that may affect our systems and Customer Personal Data. The program uses continuous logging and monitoring, documented playbooks, clear roles and escalation paths, and an on-call incident manager. Once an incident is confirmed, we mobilize the right teams, prioritize based on potential impact, and communicate at material milestones. (Aligned with common industry guidance such as NIST SP 800-61 / ISO/IEC 27035; no SLAs are implied.)
Roles & governance
To ensure a consistent response, we use defined roles and escalation paths:
- Incident Lead (IL) — owns severity classification, decisions, and overall coordination.
- Product/Infrastructure Responders — investigate, contain, and remediate in their areas.
- Communications Lead — coordinates updates to customers and internal stakeholders.
- Privacy & Legal — assess regulatory obligations and advise on notification content/timing.
What we mean by a “Security Incident”
An event that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Personal Data processed by the Services. See the DPA for the full definition.
Signals that can trigger triage
- Infrastructure or application alerts; anomaly/abuse detections; rate-limit alarms
- Authentication anomalies (suspicious logins, brute-force, token misuse)
- Data-access anomalies (unusual export/download behavior)
- Vulnerability or threat intelligence that materially affects our stack
- Cloud provider or subprocessor advisories impacting confidentiality/integrity/availability
- Customer reports via support channels
Actions & lifecycle
Our playbooks follow a repeatable lifecycle with defined owners:
Detect → Validate & prioritize → Contain → Eradicate & remediate → Recover → Post-incident review.
What we do in practice
- Staffing & escalation — assign an incident lead; add engineers/operations; notify leadership as appropriate.
- Containment — isolate affected components, revoke credentials/keys, block malicious sources, and apply compensating controls.
- Eradication & remediation — remove artifacts, patch or change configs, rotate secrets, and validate fixes.
Detection, analysis & classification
We detect, analyze, and classify potential security incidents through an initial triage. Classification uses a 0–3 severity model (see Incident severity categorization) to set urgency, staffing, and update cadence; triage outcomes then drive the steps in Actions & lifecycle.
Detection signals & tooling
We aggregate telemetry from platform monitoring and logging, cloud-provider security services, application audit logs, API/webhook analytics, and vendor/subprocessor notifications. Customer reports are tracked in support systems and linked to the incident record.
Incident severity categorization
We classify confirmed incidents by potential impact on Customer Personal Data and service integrity. Higher severity drives staffing and update cadence; it does not create fixed timelines or SLAs.
| Severity | Description |
|---|---|
| 0 | Crisis — Core functions down; platform risk; likely large-scale exposure. |
| 1 | Critical — Confirmed access/exfiltration; urgent containment. |
| 2 | Major — Contained exposure; subset of systems/users. |
| 3 | Minor — Low-impact/near-miss; no evidence of access. |
Indicators we consider include number of customers affected, sensitivity of data, duration/ease of exploitation, impact on availability, and likelihood of further misuse.
Detection & analysis
We validate the signal, scope the impact, and decide whether Customer Personal Data may be involved. Analysis typically covers:
- Scope — systems/components, regions, dependencies, and blast radius
- Actor & vector — abuse patterns, credential posture, exploited controls
- Data touch — whether Customer Personal Data was accessed, altered, or exfiltrated
- Evidence — logs/artifacts preserved for investigation and timeline building
Findings feed the severity model (0–3) and drive next actions—containment, eradication, recovery, and customer communications.
Roles during initial triage
Depending on impact, triage may involve an Incident Commander/Lead, security engineering, SRE/operations, product owners, and (where relevant) privacy/legal for assessments related to Customer Personal Data.
Decision gates (outcomes of triage)
- Is it a security incident? If not, we document and close as an event/false positive.
- Severity assignment (0–3) to align urgency and staffing.
- Customer Personal Data involved? If yes or suspected, we prioritize containment, begin evidence collection for DPA notification obligations, and coordinate customer guidance.
- Communication path selected by severity and audience (see *Customer communications & notifications*).
Quick examples (mapping to the model)
- Confirmed credential leak with use against production → 1 — Critical
- Region-level outage with no evidence of data exposure → 2 — Major
- Platform-wide outage with potential broad data exposure → 0 — Crisis
- Replay attempts blocked by webhook signing → 3 — Minor
Third parties and subprocessors
If a Subprocessor is involved, we coordinate with them and relay relevant information we receive, to the extent permitted. Subprocessors operate under contractual security and privacy obligations; see our DPA for definitions and oversight. Customer-enabled third-party apps, carriers, or connectors operate under their own terms and privacy notices. You decide which integrations to enable and what scopes to grant (see the Shared Responsibility Model). If an integration contributes to an incident, we will include relevant guidance (for example, rotate keys, revoke tokens, review logs) in our customer communications.
Recovery
We restore services safely and verify that mitigations hold before returning to normal operations. Recovery focuses on integrity, continuity, and clear customer guidance—no SLAs are implied.
What recovery includes
- Service restoration — bring components back online behind safeguards; gradually re-enable features and integrations (canary where applicable).
- Data integrity — verify storage integrity; restore from backups if needed; reconcile queues/jobs/webhooks and backfill missed events where safe.
- Secrets & access — confirm rotated credentials/keys are fully propagated; re-issue tokens where required; keep least-privilege controls in place.
- Heightened monitoring — run enhanced logging/alerts for a sustained period; watch key health metrics for regression.
- Customer guidance — share any actions we recommend (for example, re-authenticate an integration, rotate a key, re-enable a webhook, or review audit logs).
Exit criteria
Normal metrics sustained, no indicators of compromise in logs, fixes verified by tests, and Incident Lead sign-off. An “all-clear” update may be sent per Customer communications & notifications.
Post-Incident Review & Improvements
We run a Post-Incident Review (PIR) after incidents to capture causes, impact, and improvements. PIR is a learning artifact, not an SLA or formal notice timeline (statutory notifications follow the DPA).
When we do a PIR
- Severity 0 — Crisis: full PIR required.
- Severity 1 — Critical: full PIR required.
- Severity 2 — Major: lightweight PIR focused on containment, residual risk, and customer guidance if there was exposure or customer action is recommended; otherwise we track improvements internally.
- Severity 3 — Minor: internal note only (symptom, fix, prevention), grouped in periodic reviews.
The same indicators used to classify severity (e.g., number of customers affected, sensitivity of data, and duration/ease of exploitation) guide whether a Severity 2 PIR needs external guidance.
What a PIR includes (full or lightweight)
- Summary & timeline — detection → triage → containment → eradication → recovery → post-incident actions
- Impact & data handling — affected systems/functions; whether Customer Personal Data was involved; scope and evidence
- Root cause analysis — immediate cause(s), contributing factors, and systemic gaps
- Customer guidance (if applicable) — actions we recommend (e.g., rotate credentials, review audit logs, revoke unused connections)
- Fixes shipped — mitigations, hardening, monitoring, and backstops
- Owned follow-ups — corrective & preventive actions with owners and target dates; verification plan (tests/metrics) and rollback risks
How we share outcomes
Customer-safe PIR summaries are shared via support channels and direct communications to the designated Security Contact/Administrators; we may add a help-center follow-up for broad-impact issues. General service-availability updates may be provided via support channels (and a status page if/when available); these do not limit our DPA notice obligations where Customer Personal Data is affected.
Continuous improvement
PIR actions feed into our hardening backlog. We review repeat patterns (for example, auth scope reviews, key rotation, marketplace-app permissions, webhook-secret handling) and close the loop in subsequent PIRs. Security Measures remain subject to technical progress; we may update them provided overall protection is not reduced.
Customer communications & notifications
Once we confirm an incident involving Customer Personal Data, we notify affected customers without undue delay. The initial notice may be brief; we’ll follow up with material updates as facts are established and a closure summary after remediation. Notification is not an acknowledgment of fault (see DPA §4.2). To report a suspected incident, use the channels listed in How to Contact Shipber and please do not include credentials or other secrets.
Recovery confirmation
When recovery is complete, we provide an “all-clear” update summarizing what was restored, any residual risk we are watching, and any customer actions (if applicable). Communications are sent via support channels (and a status page if/when available) and do not limit our DPA notice obligations where Customer Personal Data is affected.
Outages and vulnerabilities
For service availability updates, refer to our support communications (and a status page if/when available).
To report a product vulnerability (not an account-specific incident), use the channels in How to Contact Shipber with the subject “Vulnerability Report”.
Note: This page is guidance. Contractual commitments are set out in the Shipber Services Agreement and the DPA. If there is any conflict, the Legal version controls.
Comments
0 comments
Article is closed for comments.