Security Incident Response Policy

Version 1.0 · Review cycle: annually, and following any Severity 1 or Severity 2 incident.

1. Purpose

This policy defines how Vault47 identifies, contains, investigates and reports security incidents, and establishes the roles and timeframes that apply when one occurs.

2. Definition

A security incident is any event that compromises, or may reasonably have compromised, the confidentiality, integrity or availability of platform data or systems. This includes:

• Unauthorised access to Customer data or personal data.
• Exposure or suspected exposure of credentials or access keys.
• Failure of access controls resulting in data being accessible across account boundaries.
• Compromise of an account holder's credentials.
• Introduction of malicious code, including through a third-party dependency.
• Loss or corruption of data without a verified recovery path.
• Extended unavailability of the platform.
• Notification from a sub-processor of a breach affecting Vault47 data.

Routine defects with no data exposure, isolated user access issues, and scheduled maintenance are not security incidents.

3. Severity classification

Where severity is uncertain, the incident is treated at the higher level until established otherwise.

4. Roles

Roles are assigned by title at the outset of every incident. One individual may hold more than one role, provided the assignment is explicit and recorded.

5. Response procedure

Step 1 — Record. An incident record is opened immediately, capturing the time of detection, the source of the report, and the initial observation. All subsequent activity is timestamped.

Step 2 — Classify. The Incident Lead assigns a severity level within one hour and appoints the roles above. Where personal data may be involved, the notification period in §6 begins at this point, not on conclusion of the investigation.

Step 3 — Contain. Containment takes priority over root cause analysis. Measures may include revoking and rotating credentials and access keys, terminating active sessions, disabling the affected function or endpoint, restricting database access, or suspending the platform where isolation failure is confirmed and cannot otherwise be arrested. Evidence is preserved before remediation begins. Logs are captured prior to any credential rotation or system reset.

Step 4 — Investigate. Establish what was accessed, whose data was involved, the volume, the period concerned, and the mechanism of access. Confirmed findings are recorded separately from suspected ones. Notification is based on confirmed scope but is not delayed pending complete certainty.

Step 5 — Remediate and recover. Address the root cause, restore from verified backups where integrity is affected, and confirm the vulnerability is closed before service is restored. Verification is performed without use of a live Customer account.

Step 6 — Notify. In accordance with §6.

Step 7 — Review. Within 10 business days of closing any S1 or S2 incident, a written review is produced covering the timeline, root cause, effectiveness of the response, and corrective actions with assigned owners and target dates. Reviews are conducted without attribution of individual fault.

6. Notification

The notification period commences on awareness of the incident, not on confirmation of its full extent. Where the position is incomplete, an initial notification is made and supplemented as the investigation progresses.

Customers act as controllers in respect of their own client data. Where an incident affects that data, Vault47 notifies the Customer promptly so that the Customer may discharge its own obligations.

7. Communication standards

• External communication is issued solely by the Communications Lead.
• Statements are limited to established fact, actions taken, and matters under investigation. Speculation is not communicated.
• Internal system identifiers, infrastructure detail and administrative endpoints are not disclosed.
• No assurance that data was unaffected is given unless positively established.
• Notifications are issued from a monitored address.

8. Contact

Reports received through any channel are escalated to the Incident Lead on receipt.

9. Preparedness

• This policy is reviewed annually and following any S1 or S2 incident.
• A scenario walkthrough is conducted at least annually.
• Backup restoration is tested on a defined schedule; an untested backup is not treated as a valid recovery path.
• Role assignments and escalation contacts are verified at each review.

Appendix A — Initial response checklist

• Open the incident record; note time and source.
• Assign the Incident Lead.
• Assign a severity level.
• Capture and preserve logs before making changes.
• Rotate any potentially exposed credentials.
• Terminate affected sessions.
• Determine whether personal data may be involved; if so or if unclear, start the notification clock.
• Assign Technical Responder, Communications Lead and Scribe.
• Decide whether the platform remains in service.
• Set and hold the next review checkpoint.