Incident Response Plan
Movik, Inc. · Information Security Program
- Document
- Incident Response Plan
- Version
- 1.0
- Effective date
- August 19, 2026
- Owner
- Security Program Owner (CEO)
- Review cycle
- Annually, and after any declared incident
- Classification
- Internal — shareable with partners
1Purpose and scope
This plan implements clause 13 of Movik’s Information Security Policy. It defines how Movik detects, classifies, contains and reports security incidents affecting its systems or the data it holds. It applies to all personnel and contractors, and to incidents originating at Movik, at a third-party provider, or in a customer’s use of the service.
2Definitions
- Event. Any observable occurrence in a system or network. Most events are routine.
- Incident. An event that compromises, or plausibly threatens, the confidentiality, integrity or availability of Movik systems or data, or that violates this program.
- Breach. An incident in which unauthorized acquisition of, or access to, customer or personal information has occurred or cannot be ruled out. A breach triggers the notification obligations in clause 7.
3Roles
| Role | Held by | Responsibility |
|---|---|---|
| Incident Lead | Security Program Owner (CEO), or delegate | Declares and classifies the incident, owns the response, authorizes containment actions with customer impact, approves all external communication, and closes the incident. |
| Technical Responder | Engineering | Investigates, contains, eradicates and recovers. Preserves evidence before remediation. Maintains the incident timeline. |
| Communications | Incident Lead, or delegate | Notifies customers, partners and regulators under clause 7. Single point of external contact; no one else communicates externally about an incident. |
| Reporter | Any person | Reports immediately on suspicion. Takes no investigative action that could destroy evidence or alert an intruder. |
Movik is small enough that one person may hold more than one role. The Incident Lead role is never held by the person whose change or access is under investigation; in that case it passes to a delegate.
4Severity classification
The Incident Lead assigns severity at declaration and revises it as facts change. Severity is assigned on plausible worst case, not on what is confirmed — an incident is downgraded once scope is established, never upgraded late.
| Severity | Definition | Examples | Response |
|---|---|---|---|
| SEV1 — Critical | Confirmed or suspected unauthorized access to customer financial data, funds, or the production database; ransomware; loss of control of the AWS account. | Credential compromise with production access; exfiltration indicators; fraudulent disbursement. | Immediate. Incident Lead engaged without delay, at any hour. Containment takes precedence over availability. |
| SEV2 — High | Credible threat to customer data or funds not yet realized, or loss of a security control. | Exposed credential with unclear use; authorization bypass; WAF or logging disabled; provider breach affecting Movik data. | Within 1 hour during business hours, within 4 hours otherwise. |
| SEV3 — Moderate | Security-relevant failure with no evident data exposure. | Repeated authorization failures from one source; unpatched high-severity dependency in production; phishing attempt against personnel. | Within 1 business day. |
| SEV4 — Low | Policy deviation or hygiene issue requiring tracking. | Access found beyond role during review; misconfiguration with no exposure. | Logged to the risk register and handled in normal work. |
5Reporting and detection
- All personnel must report a suspected incident immediately on suspicion, without first establishing whether it is genuine. A false alarm costs minutes; a delayed report costs the containment window.
- Internal reports go to the Security Program Owner directly, and to support@movik.us as the recorded channel.
- External reports — from researchers, customers or providers — are accepted at the same address and routed to the Incident Lead on receipt. Movik does not pursue good-faith researchers who practice responsible disclosure.
- Automated detection comes from centralized logging and alerting on authentication failures, authorization denials, privileged actions, configuration changes and infrastructure alarms, as required by clause 12 of the Information Security Policy.
- Providers are contractually required to notify Movik of incidents affecting Movik data; such notifications are treated as incidents under this plan from the moment they arrive.
6Response procedure
6.1 Triage and declaration
The Incident Lead confirms the report, assigns severity under clause 4, opens an incident record, and starts a timeline. The record captures what is known, what is assumed, and what remains unverified — kept separate, because conflating them is how incidents are mis-scoped. Every subsequent action and its time is appended.
6.2 Containment
Containment limits further damage and takes precedence over restoring service. Depending on the incident: revoke sessions and rotate the affected credentials, disable the affected identity or role, revoke provider tokens, block the source at the edge, remove the affected component from service, or disable the affected feature. Actions that interrupt customer service require the Incident Lead’s authorization; actions that stop active data loss do not and are taken immediately.
6.3 Evidence preservation
Before remediation alters the environment, responders capture the relevant logs, configuration state and affected records, and record their own actions. Compromised credentials are rotated rather than deleted where the record is needed. Evidence is stored with access limited to the response team, and is retained under legal hold per clause 7 of the Data Retention and Disposal Policy if litigation or regulatory inquiry is anticipated.
6.4 Eradication and recovery
The root cause is removed — not merely the symptom — and the affected systems are restored from a known-good state. Before service is restored, responders confirm the access path used is closed, no persistence remains, and monitoring is in place to detect recurrence. The Incident Lead authorizes restoration and closes the incident.
7Notification
Notification is the Incident Lead’s decision and the Communications role’s execution. Movik notifies on the basis of plausible exposure; it does not wait for confirmation of misuse.
| Recipient | When | Trigger |
|---|---|---|
| Affected customers | Without undue delay, and within the period applicable law requires | Their data was, or may have been, accessed or acquired without authorization. |
| Banking, payments and data partners | On the schedule the relevant agreement specifies, and promptly in any event | An incident affects data received from or shared with that partner, or affects the integrity of the integration. |
| Regulators and state authorities | Within statutory deadlines applicable to the affected records and residents | A breach of personal information as defined by the applicable statute. |
| Law enforcement | At the Incident Lead's discretion, or where required | Criminal conduct, fraud, or extortion. |
| Insurers and counsel | As required by policy or engagement terms | Any SEV1, and any incident with legal exposure. |
Notifications state what happened, what data was involved, when it occurred, what Movik has done, and what the recipient should do. Movik does not speculate about cause or scope in an external communication before it is established, and issues a correction if an earlier statement proves wrong.
8Post-incident review
Every SEV1 and SEV2 incident receives a documented review within ten business days of closure, led by the Incident Lead with everyone involved.
- The review establishes the timeline, the root cause, why detection took as long as it did, and what limited or worsened the impact.
- It produces corrective actions, each with an owner and a date, entered in the risk register and tracked to closure. An action without an owner is not an action.
- Reviews address cause, not blame. Personnel who report incidents or disclose their own mistakes in good faith are not disciplined for having done so.
- Where the review finds a policy clause that did not reflect practice, the clause is corrected under clause 20 of the Information Security Policy.
9Testing
Movik exercises this plan at least annually with a tabletop scenario covering at least one SEV1 case — typically compromise of an administrative credential with production access, or a provider breach affecting customer financial data. The exercise tests whether the plan can actually be followed: whether contacts are current, whether the containment steps are available to the people on call, and whether notification deadlines are achievable. Findings are treated as corrective actions under clause 8, and the plan is revised accordingly.
10Review
This plan is reviewed at least annually by the Security Program Owner, after every declared SEV1 or SEV2 incident, and on any material change to Movik’s architecture, provider set or notification obligations. Revisions are versioned and the effective date in the document control block reflects the current version.
To report a suspected vulnerability or incident: support@movik.us.