Business Continuity and Disaster Recovery Plan
Movik, Inc. · Information Security Program
- Document
- Business Continuity and Disaster Recovery Plan
- Version
- 1.0
- Effective date
- August 19, 2026
- Owner
- Security Program Owner (CEO)
- Review cycle
- Annually, and after any invocation
- Classification
- Internal — shareable with partners
1Purpose and scope
This plan implements clause 14 of Movik’s Information Security Policy. It defines how Movik sustains and restores its service and records after a disruption. Its scope is the production application and API, the production database, document storage, identity infrastructure, the third-party providers the service depends on, and the personnel and processes required to keep funding obligations to carriers moving while systems are degraded.
Movik operates no data centers. Physical resilience — power, cooling, fire suppression and facility redundancy — is inherited from Amazon Web Services. This plan therefore addresses what Movik controls: configuration, data, dependency and process.
2Business impact
Carriers use Movik for working capital, frequently to fund fuel and driver pay before a load settles. A funding delay has an immediate operational consequence for a customer, so availability of the funding path is the highest-priority recovery objective, ahead of reporting, analytics and administrative functions.
| Function | Priority | Impact of unavailability |
|---|---|---|
| Funding and disbursement | Critical | Carriers cannot access working capital already earned. Direct operational harm to customers. |
| Authentication and account access | Critical | No customer can transact; blocks every other function. |
| Invoice and document submission | High | Funding requests queue; recoverable once service resumes, with delay. |
| Underwriting and credit assessment | High | New advances stall; existing relationships can be serviced on prior decisions. |
| Reporting, analytics, marketing site | Low | No customer financial impact. |
3Roles
- The Security Program Owner declares a continuity event, authorizes recovery actions and manual processing under clause 6, and owns communication with customers and partners.
- Engineering executes technical recovery, performs and verifies restores, and reports status against the objectives in clause 4.
- Where a disruption is caused by a security incident, this plan operates alongside the Incident Response Plan, and the Incident Lead holds precedence on containment decisions — service is not restored ahead of containment.
4Recovery objectives
Recovery time objective (RTO) is the target time to restore function. Recovery point objective (RPO) is the maximum acceptable data loss measured in time. These are targets against which performance is measured in testing, not guarantees.
| Asset | RTO | RPO | Basis |
|---|---|---|---|
| Application and API | 4 hours | Not applicable — stateless | Reproducible from source via the deployment pipeline; no state to recover. |
| Production database | 8 hours | 5 minutes | Managed point-in-time recovery within the retention window. |
| Document storage | 4 hours | Near zero | Managed object storage with built-in redundancy across facilities. |
| Identity and authentication | 4 hours | Near zero | Managed identity provider; configuration reproducible. |
| Loss of an entire AWS region | 48 hours | 5 minutes | Redeploy to an alternate region from source and restore the database from backup. |
5Backup and restore
- The production database is backed up automatically and continuously, encrypted at rest, with point-in-time recovery across the retention window defined in the Data Retention and Disposal Policy.
- Document storage is held in managed object storage that maintains redundant copies across physically separate facilities.
- Infrastructure and application configuration are held in version control, so the environment is rebuilt by deploying a known commit rather than reconstructed by hand.
- Backups are encrypted, access to them is restricted on the same basis as production data, and their retention is governed by the Data Retention and Disposal Policy.
- Restores are tested, not assumed. A restore is performed and verified at least annually into an isolated environment, and the elapsed time is recorded against the objectives in clause 4. A restore that misses its objective is a finding entered in the risk register.
- Where a restore is performed for continuity reasons, deletions already applied under the Data Retention and Disposal Policy are reapplied to the restored environment, so recovery does not resurrect disposed records.
6Disruption scenarios
6.1 Loss of an availability zone
Managed services fail over within the region. Engineering confirms service health and capacity. No data loss is expected and no declaration is required unless customer impact persists beyond one hour.
6.2 Loss of a region
The Security Program Owner declares a continuity event. Engineering redeploys the application to an alternate region from version control and restores the database from backup, targeting the objectives in clause 4. Customers and partners are notified under clause 7 with a status channel and expected restoration window.
6.3 Data corruption or destructive action
Where records are corrupted, or destroyed by error, defect or malicious action, the database is restored to a point in time before the event. Where partial recovery is required, the affected records are extracted from a restored copy and reapplied rather than rolling back the whole system. Any suspicion of malicious cause invokes the Incident Response Plan, and containment precedes restoration.
6.4 Ransomware
Movik does not pay ransom demands. Recovery is by restoration from backup to a rebuilt environment, with credentials and keys rotated before service resumes and the access path confirmed closed. The event is handled as a SEV1 under the Incident Response Plan.
6.5 Loss of a critical provider
Where a provider becomes unavailable — bank connectivity, identity verification, document execution, messaging or credit data — the dependent function degrades rather than the whole service failing. Funding decisions continue on existing verified information and prior assessments, and the affected step is completed manually under clause 6.6 or deferred with the customer informed. Provider concentration and substitutability are reviewed at each annual cycle.
6.6 Manual continuity of funding
Where the application is unavailable but funding obligations remain, the Security Program Owner may authorize manual processing: funding requests accepted by email or telephone, verified against records available from a restored copy or from partner systems, approved by the Security Program Owner, and executed through the banking partner directly. Every manual action is recorded contemporaneously and reconciled into the system of record once service resumes. Manual processing does not suspend the controls in the Access Controls Policy: approval remains attributable to a named individual.
6.7 Loss of key personnel
Because Movik is small, single-person dependency is a live risk rather than a theoretical one. Administrative access is held by more than one individual, recovery credentials and account recovery paths are documented and stored so they survive the unavailability of any one person, and infrastructure is defined in version control rather than in an individual’s knowledge. This concentration is carried in the risk register and reviewed at each cycle.
7Communication during a disruption
- The Security Program Owner is the single point of external communication and issues the first customer notification as soon as customer impact is established, without waiting for a restoration estimate.
- Updates are issued at a stated interval until resolution, and a final notice confirms restoration and states whether any data was lost.
- Banking, payments and data partners are notified where a disruption affects an integration or Movik’s ability to meet an obligation to them, on the schedule the relevant agreement requires.
- Where the disruption is also a security incident, all external communication follows clause 7 of the Incident Response Plan.
8Testing
At least annually Movik performs a verified database restore with the elapsed time recorded against clause 4, and exercises one scenario from clause 6 as a tabletop — alternating between region loss, provider loss and loss of key personnel across cycles. Testing confirms that documented recovery paths, credentials and contacts are current and usable. Results, including any objective that was missed, are recorded and entered in the risk register as corrective actions with owners and dates.
9Review
This plan is reviewed at least annually by the Security Program Owner, after any invocation, after any test that misses an objective, and on any material change to Movik’s architecture, hosting configuration or critical provider set. Where a change alters what is achievable, the objectives in clause 4 are revised to what can be demonstrated rather than left as a target the platform no longer supports. Revisions are versioned and the effective date in the document control block reflects the current version.