MCC-DRBC — Disaster Recovery and Business Continuity Plan v1.0-draft

Document control

Field	Value
Document code	MCC-DRBC (code assigned by the programme administration for this consultation; entered in the Document Register on adoption)
Title	Disaster Recovery and Business Continuity Plan
Version	1.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	4 September 2026
Tier	Tier 5 (operational plan). The recovery objectives are the Governing Board's; this plan is the instrument that carries them.
Effective date	None. This plan is not in force, and it commits the Programme to no recovery objective.
Document owner	Programme Administrator (transitional, until a Secretariat is staffed — FD-2026-10-01 Schedule 1, C3)
Approved by	Not approved. Prepared for public consultation.
Decision basis	MCC-800 art. 91–94 (Disaster Recovery and Business Continuity), art. 18–21 (Performance and Availability), art. 88; MCC-100 cl. 0218–0219; MCC-850 art. 12 and 12.1; MCC-CADCP cl. 0144; MCC-BPM cl. 0084; MCC-700 cl. 4.3.3; Transparency Policy art. 3(4) and 4.1–4.2. Drafts of the rewritten suite, not in force: MCC-ISS (MCC-820) v1.0-draft §15 and MCC-810 v1.0-draft, put to consultation with this Plan; MCC-800 v2.0-draft §20–21, put to consultation with this Plan.
Supersedes	None (new document). This is the Disaster Recovery Plan required by MCC-800 art. 91, which has never existed.
Language convention	British English; RFC-style normative verbs.
Classification	Public — consultation draft
Consultation period	30 days (FD-2026-10-01 Schedule 1, C4), from the opening recorded on the consultation register (FD-2026-09-04 item 2; FD-2026-10-01 item 5)

NOTE (non-normative). This plan asserts no recovery capability the Programme does not have.

MCC-800 art. 91 has required a documented Disaster Recovery Plan since 1 April 2026. None was ever written. This DRAFT is the first. It was prepared by reading the deployed architecture rather than the intended one, and the central finding is stated at the front rather than buried in an annex:

The Supabase project that holds the registry is on the free plan. Supabase's published position is that it backs up "all Pro, Team, and Enterprise Plan projects on a daily basis" and recommends that "free tier plan projects regularly export their data … and maintain off-site backups". Point-in-Time Recovery is available only to Pro, Team and Enterprise projects. No export has ever been taken. No backup or restore script exists anywhere in the repository. No restoration or failover exercise has ever been run.

The recovery point objective of 1 hour and recovery time objective of 4 hours stated in MCC-800 art. 21, MCC-CADCP cl. 0144 and MCC-850 art. 12 are therefore not being met, have never been met, and cannot be met on the present plan. Section 5 records what is actually true; Section 6 states what the Board would have to buy and build for the in-force figures to become achievable.

Nothing has been lost. The registry holds zero credit units, zero credit batches and zero issuance requests. The exposure today is two project submissions, six organisations, sixteen platform user records and the audit trail. That is the cheapest moment this problem will ever be fixed in.

Consultation questions

Each point below is open for comment. A proposal is the administration's proposal, put to consultation under founder direction FD-2026-10-01; it is not a rule in force. The suite is to be adopted as one instrument once its longest consultation period has closed (FD-2026-10-01 Schedule 1, C4). Because it includes the Constitution, whose amendment is within the competence of the constituted Governing Board (FD-2026-08-24 item D11, recorded in the decision register as attested by the founder, with no executed copy filed), each point below is decided by the Governing Board on adoption of the suite; a clause of this text that provides another route for adopting it alone is itself open to comment.

1. Clause 3.8 — infrastructure/terraform/. Proposed: no proposal is made between deleting the directory and moving it with a label marking it as an unbuilt proposal; under either course it is not treated as a description of production. Basis: Annex, item 13; FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on which course to take.

2. Clause 6.2 — recovery point objective for registry data. Proposed: 24 hours before first issuance; 1 hour from the day issuance is enabled. Basis: the drafting proposal (Annex, item 3); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on the objective and its two stages.

3. Clause 6.3 — recovery time objective for the registry. Proposed: 24 hours before first issuance; 4 hours from the day issuance is enabled. Basis: the drafting proposal (Annex, item 4); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether a rehearsed 24-hour objective is the right standard until issuance is enabled.

4. Clause 6.4 — recovery objectives for object storage. Proposed: RPO 24 hours and RTO 24 hours, from adoption. Basis: the drafting proposal (Annex, item 5); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether these objectives are adequate.

5. Clause 6.5 — availability objective. Proposed: a single figure, stated once, in whichever instrument survives the MCC-800 v2.0 rewrite, measured by a probe whose output is published; no figure is proposed. Basis: the drafting proposal (Annex, item 1); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on the figure, given the conflict between 99.5% (MCC-800 art. 18), 99.9% (MCC-100 cl. 0219) and 99.9% in business hours (MCC-850 art. 12).

6. Clause 6.6 — destination for off-site exports. Proposed: no destination is proposed — this Plan names none, and states only that the destination must be an account the Programme controls and not the Supabase or Vercel account, so that a compromise or closure of either does not take the backups with it. Basis: FD-2026-09-04 item 5 (an off-site export of the database and of object storage to be established); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on the criteria a destination must meet.

7. Clause 7.2.1 — an external uptime probe. Proposed: no proposal is made on whether a probe independent of both providers is commissioned. Basis: FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether such a probe should be required.

8. Clause 7.4.2 — secret storage and key rotation. Proposed: no proposal is made on whether secrets move to a dedicated secret manager, or whether the Supabase service-role key is rotated on a schedule rather than only on suspicion. Basis: FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on both points.

9. Clause 7.5.3 — access to the Supabase and Vercel accounts. Proposed: no proposal is made — the Plan does not state who holds access to the two accounts, whether they require multi-factor authentication, or whether more than one person can reach them, and sets no requirement for them. Basis: FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on what the Plan should require of access to the hosting accounts.

10. Clause 7.6.3 — malware scanning in production. Proposed: no proposal is made on whether upload scanning should be required in production, such that a scanner outage blocks uploads rather than permitting unscanned ones. Basis: Annex, item 14; FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether scanning should be mandatory in production.

11. Clause 7.7.1 — an inventory of environment variables. Proposed: no proposal is made — an inventory of environment-variable names is kept in the repository (apps/web/.env.example) but is incomplete, and the Plan sets no requirement for it. Basis: FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether the Plan should require one.

12. Clause 8.2 — who declares and owns an incident. Proposed: the Programme Administrator declares an incident under this Plan and owns it until it is closed; no alternate is proposed. Basis: the drafting proposal (Annex, item 8); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on the allocation and on who the alternate should be.

13. Clause 8.5 — the Registry Oversight Authority. Proposed: until the body is constituted, its functions — including the quarterly review of backup and disaster-recovery procedures under MCC-700 v3.0 cl. 4.3.3 — are exercised by the Governing Board, under a transitional appointments schedule. Basis: FD-2026-10-01 Schedule 1 (C5); FDP-2026-001 C5; Annex, item 9. Decided by: the Governing Board on adoption of the suite; the Board constitutes the body and makes appointments to it. Comments are invited on the transitional arrangement.

14. Clause 8.7 — the Registry Operator pending incorporation. Proposed: no entity is named as Registry Operator: the Programme's operating entity has not yet been incorporated, and the administration proposes that it be a Norwegian aksjeselskap (AS). The registry continuity and wind-down plan that MCC-800 v2.0-draft cl. 21.1 would require is a separate instrument and is not proposed here. Basis: FD-2026-10-01 item 3 and Schedule 1 (C1); Annex, item 10. Decided by: the Governing Board on adoption of the suite; the entity's name and jurisdiction are reserved to the Board (FD-2026-09-04 item 6). Comments are invited on how the duties of MCC-800 art. 91–92 should be carried until the entity exists.

15. Clause 9.3 — an out-of-band notification route. Proposed: an out-of-band route — a status page hosted outside Vercel, or a mailing route that does not depend on the platform — so that the duty at MCC-800 art. 93(a) and (b) can be discharged during the outage it addresses. Basis: the drafting proposal (Annex, item 11); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on which route is preferable.

16. Clause 10.4 — test cadence. Proposed: quarterly for the restore exercises T1 and T2 and annually for the rest, resolving the conflict between MCC-800 art. 91 (annually) and MCC-850 art. 12 (quarterly) in favour of the stricter reading for the exercises that matter most. Basis: the drafting proposal (Annex, item 2); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on the cadence.

---

1. Purpose, scope and application

1.1 This Plan discharges MCC-800 art. 91, which requires that "The Registry Operator shall maintain a documented Disaster Recovery Plan (DRP) that is tested at least annually through a simulated failover exercise." It states what the Programme would do to restore the registry and its dependent services after a disruptive event, and states honestly what it is presently able to do.

1.2 This Plan applies to every system on which the MCC Registry depends, whether operated by the Programme or by a supplier. Section 4 lists them as deployed.

1.3 This Plan does not state security controls. Those are the MCC Information Security Standard's, and the interface between the two instruments is set out in Section 11. Where this Plan and the Information Security Standard could both be read to state a control, the Information Security Standard governs and this Plan is read as the continuity application of it.

1.4 This Plan states no fact about the architecture that was not verified against the running system on 4 September 2026. Where an in-force instrument describes an architecture that is not deployed, that divergence is recorded in Section 3 rather than repeated.

1.5 Where a duty under this Plan would fall on a body that has not been constituted, the duty is not assigned. It is recorded in Section 8 as a gap, with the decision that would close it. A plan that allocates a duty to a body that does not exist has allocated nothing.

---

2. Normative basis

2.1 The following requirements are in instruments that the document register records as in force.

Instrument	Clause	Operative words
MCC-800 v1.0	art. 18	"shall maintain a minimum uptime of 99.5% measured on a rolling 30-day basis, excluding scheduled maintenance windows"
MCC-800 v1.0	art. 19	maintenance windows "shall not exceed 4 hours per month" and "shall be announced at least 72 hours in advance"
MCC-800 v1.0	art. 21	"shall maintain automated backups with a Recovery Point Objective (RPO) of 1 hour and a Recovery Time Objective (RTO) of 4 hours"
MCC-800 v1.0	art. 88	archived data "shall be stored in encrypted, geographically redundant storage and shall remain retrievable within 48 hours"
MCC-800 v1.0	art. 91	DRP "tested at least annually through a simulated failover exercise"
MCC-800 v1.0	art. 92	the DRP shall provide for "(a) automated database failover to a standby replica within the RTO of 4 hours, (b) application-layer redundancy across at least two availability zones, (c) DNS failover to a secondary hosting environment, and (d) manual recovery procedures for catastrophic failure scenarios"
MCC-800 v1.0	art. 93	on outage exceeding 1 hour the Registry Manager shall "(a) notify all account holders … (b) publish a status update on the MCC website, and (c) suspend all pending workflow deadlines until service is restored"
MCC-800 v1.0	art. 94	post-incident review "within 10 business days" and publication of "findings, root cause, and remediation actions"
MCC-100 v2.1	cl. 0218	"The Registry shall be backed up daily and shall have geographic redundancy to ensure disaster recovery."
MCC-100 v2.1	cl. 0219	"The Registry shall achieve 99.9% uptime availability and shall have documented disaster recovery procedures."
MCC-850 v1.1	art. 12	"99.9% uptime during business hours"; "Backup systems and failover capability to ensure continuity"; "Disaster recovery plan tested quarterly; recovery time objective (RTO) <4 hours"
MCC-850 v1.1	art. 12.1.6	continuous Degraded Mode "exceeding twenty-four hours shall be treated as an incident under Article 35"
MCC-CADCP v1.0	cl. 0144	"The platform shall implement automated backup and disaster recovery procedures with recovery time objectives of 4 hours and recovery point objectives of 1 hour."
MCC-BPM v1.0	cl. 0084	"The Registry Operator shall maintain backup systems and disaster recovery protocols ensuring buffer pool data integrity."
MCC-700 v3.1 (FD-2026-08-24 item D11)	cl. 4.3.3	"Registry Oversight Authority shall meet quarterly and shall review registry audit reports, IT security assessments, and backup/disaster recovery procedures."
Transparency Policy v1.1	art. 3(4)	"Backup and disaster recovery procedures" are withheld from public disclosure as Security Information

2.2 The in-force figures conflict with one another, and this Plan does not pretend otherwise:

2.2.1 Availability is 99.5% on a rolling 30-day basis under MCC-800 art. 18, and 99.9% under MCC-100 cl. 0219, and 99.9% "during business hours" under MCC-850 art. 12. Three instruments, three numbers, no reconciliation.

2.2.2 The disaster recovery plan is tested "at least annually" under MCC-800 art. 91 and "quarterly" under MCC-850 art. 12. Two instruments, two cadences.

2.2.3 MCC-800 art. 107, which took effect on 1 April 2026, relaxes availability to 95% "During the Pilot Phase (Months 1–6)" and does not say from what date those months run. GB-2026-001 resolution 1.3 (recorded in the decision register as attested by the founder, with no executed copy filed) records that the Pilot Phase under MCC-700 §10.1 began on 26 August 2026; whether that is the phase art. 107 refers to is not settled by either text.

2.2.4 These conflicts are recorded, not resolved. Resolving them is a Board decision and is item 1 of the Annex.

2.3 The following requirements are in drafts of the rewritten suite and are not in force: MCC-ISS (MCC-820) v1.0-draft is put to consultation with this Plan, and so is MCC-800 v2.0-draft. They are cited so that this Plan does not diverge from the suite as it is being rewritten.

2.3.1 MCC-800 v2.0-draft cl. 20.2 would require "a documented and tested business continuity and disaster recovery plan meeting the recovery objectives fixed in the Registry Architecture Specification"; cl. 20.3 would require backups "with integrity verification and geographic redundancy" and restoration "tested at least annually"; cl. 20.5 and 20.6 restate the outage-notification and post-incident-review duties of art. 93–94.

2.3.2 MCC-800 v2.0-draft cl. 1.6 would move every availability percentage, latency figure and recovery objective out of the Standard and into a Registry Architecture Specification, which does not yet exist. This Plan is drafted so that it survives that move: it states the objectives as proposals to the Board (Section 6), not as findings, so that whichever instrument ends up carrying them can carry these.

2.3.3 MCC-ISS (MCC-820) v1.0-draft cl. 15.1 would provide that "Backup, disaster recovery and business continuity for the registry are governed by MCC-800 Section 20 under this Standard's protections". Section 11 of this Plan is written to that division.

2.3.4 MCC-800 v2.0-draft cl. 21.1 would additionally require a registry continuity and wind-down plan covering operator failure or insolvency, planned cessation and transfer to a successor operator. That is a different instrument from this one and is not drafted here. This Plan covers recovery of a service that the Programme intends to keep running. It is recorded as a gap at clause 8.7.

---

3. The architecture as deployed, and the architecture as written

3.1 Before any recovery procedure can be written, the system it recovers must be established. The following was verified against the running system on 4 September 2026.

3.2 Application tier. A Next.js application deployed on Vercel. vercel.json pins "regions": ["arn1"] — a single region, Stockholm. Six scheduled functions are declared there: cron-fetch-all (daily 03:00), vessels/cron-evaluate (hourly), cron-sla (hourly at :30), cron-process-sla (daily 06:00), cron-watchdog (hourly at :15), and notifications/cron-retry-delivery (four times hourly).

3.3 Data tier. A Supabase-hosted PostgreSQL 17.6 database, project reference ifflkkpowmzjoochwavf, region eu-north-1 (Stockholm), created 25 March 2026, status ACTIVE_HEALTHY. The owning organisation is "North Capital Partners" and its subscription plan is free. The public schema holds 78 tables. Two pg_cron jobs run inside the database: registry-reconciliation-nightly (02:45 UTC) and rate-limit-gc-hourly.

3.4 Object storage. Three Supabase Storage buckets: project-documents (private, created 27 March 2026), accreditation-documents (private, created 26 August 2026) and project-images (public, created 3 September 2026).

3.5 Both tiers are in the same city. Vercel arn1 and Supabase eu-north-1 are both Stockholm. There is no second region, no standby replica, and no secondary hosting environment. MCC-800 art. 92(b) requires "application-layer redundancy across at least two availability zones" and art. 92(c) requires "DNS failover to a secondary hosting environment"; neither exists.

3.6 External dependencies. The application holds credentials for, and its behaviour depends on: Anthropic (the AI Analysis Layer model provider), Resend (outbound notification mail), Supabase Auth SMTP (account confirmation and password reset), Sentry (error reporting), NatureMetrics (eDNA sampling), and Planet, Sentinel Hub and Spire (satellite and vessel monitoring). The DocuSign client and the ClamAV upload validator were removed from the codebase on 24 August 2026 (PR #118); no external electronic-signature service is called and no upload is scanned for malware. Each is a single point of failure for the function it serves; Section 7 treats them.

3.7 The written architecture is not the deployed architecture. MCC-800 art. 14 specifies "a PostgreSQL relational database as the primary data store, an Express/Node.js API layer for business logic enforcement, and a React-based user interface". There is no Express/Node.js API layer; business logic runs in Next.js route handlers and in the database. Separately, infrastructure/terraform/main.tf in the repository describes an AWS architecture — an aws_rds_cluster with backup_retention_period = 30 in production and multi_az = true, ECS, KMS, Secrets Manager and a versioned S3 document bucket. None of it is deployed. It is a plan for a system that was never built.

3.8 Clause 3.7 is the reason this Plan was written from the running system. A disaster recovery plan derived from that Terraform would have described thirty days of automated RDS snapshots and multi-availability-zone failover, and would have been false in every operative respect. The Programme SHALL NOT treat infrastructure/terraform/ as a description of production. Whether that directory is deleted, or moved and labelled as an unbuilt proposal, is not decided. (Consultation question 1.)

---

4. Systems in scope, and what their loss costs

4.1 The following are in scope, in the order in which their loss would matter.

#	System	What is lost if it is lost	Present state
S1	Supabase Postgres (ifflkkpowmzjoochwavf)	The registry: units, batches, accounts, holdings, the audit trail, all governance and workflow records	Free plan; no self-service restore
S2	Supabase Storage (3 buckets)	Every uploaded PDD, evidence file, accreditation document and project image	Not covered by any database backup at any plan level
S3	Supabase Auth	Every person's ability to sign in, confirm an account or reset a password	8 auth users, 9 identities (1 October 2026)
S4	Vercel deployment (arn1)	The public site, the portal, the public API, and all six scheduled functions	Single region
S5	Source repository	The ability to rebuild S4	Git; hosting arrangement not verified by this Plan
S6	Secrets and credentials	The ability of S4 to reach S1, S2 and every dependency in cl. 3.6	Held in Vercel environment configuration
S7	External dependencies (cl. 3.6)	The function each serves, degraded or stopped	Each single-sourced

4.2 The exposure today is small and is stated exactly, because a plan that overstates what is at risk is as untrustworthy as one that understates it. On 4 September 2026 the registry held: 0 credit units, 0 credit batches, 0 issuance requests, 0 retirements, 0 documents; and 2 projects, 6 organisations, 16 platform user records, 8 authentication identities, 2 registry accounts, 2 AI review records, 5 human decision records and 240 audit log entries.

4.3 Clause 4.2 is a statement about 4 September 2026 and SHALL NOT be read as a permanent characterisation. The moment the first credit is issued, S1 becomes an irreplaceable record of legal entitlements, and the analysis in Section 5 becomes a live threat to those entitlements rather than a theoretical one.

---

5. The actual backup position, and its limits

5.1 This is the section the rest of the Plan depends on. It states what exists, not what is intended.

5.2 The database is on the free plan, and the free plan is not a backup plan. Supabase's published position is that "We automatically back up all Pro, Team, and Enterprise Plan projects on a daily basis", and that "We recommend that free tier plan projects regularly export their data using the Supabase CLI db dump command and maintain off-site backups." Free-plan projects are not in the list of plans that are backed up on schedule; they are given a recommendation to back themselves up. Supabase's own troubleshooting guidance adds that daily backups presently retained for free projects become accessible only "once you upgrade", and warns that "we might no longer make daily backups for free projects in the future".

5.3 Point-in-Time Recovery is not available. Supabase states that "Pro, Team and Enterprise Plan projects can enable PITR as an add-on", at a published price from approximately USD 100 per month for a 7-day retention window, and that PITR requires at least a Small compute add-on. On the free plan there is no PITR and therefore no ability to recover the database to a point before a specific destructive statement. This is the single most consequential limitation in this Plan: it is the only control that recovers from clause 7.4.

5.4 The Programme takes no backup of its own. A search of the repository on 4 September 2026 found no pg_dump or supabase db dump invocation, no backup script under scripts/, no backup job among the three GitHub Actions workflows (ci.yml, e2e.yml, visual-regression.yml), and no scheduled function in vercel.json or in pg_cron that exports data. No off-site export is evidenced anywhere in the programme record.

5.5 Nothing watches the backups, because there are none to watch. The platform watchdog (apps/web/src/app/api/monitoring/cron-watchdog/route.ts) runs hourly and asserts eight things: the SLA probe, satellite monitoring, AI degraded mode, notification delivery, auth-email delivery, the transition rulebook, per-batch credit arithmetic, and the nightly registry reconciliation. It was built specifically to detect "the ABSENCE of expected events". It contains no check that a backup exists, that one is recent, or that one can be restored. The one control on this platform designed to catch a missing heartbeat has no heartbeat to listen for here.

5.6 Object storage is not covered by any database backup, at any plan level. Supabase states plainly that "Database backups do not include objects you store via the Storage API, as the database only includes metadata about these objects. Restoring an old backup does not restore objects you deleted after that backup." Upgrading the plan would therefore protect the registry rows but not the three buckets at clause 3.4. Storage requires a separate, independently scheduled export. None exists.

5.7 Project deletion is unrecoverable. Supabase states: "When you delete a project, we permanently remove all associated data, including any backups stored in S3. This action is irreversible." No paid plan changes this. It is a control problem, not a backup problem, and it is treated at clause 7.5.

5.8 What the recovery objectives therefore actually are today. Not as commitments — as measurements.

Objective	In force	Actually achievable today	Why
RPO (registry data)	1 hour (MCC-800 art. 21; MCC-CADCP cl. 0144)	Unbounded. All data written since the last export is at risk, and no export has ever been taken	cl. 5.2, 5.4
RPO (uploaded documents)	1 hour, by the same clauses	Unbounded, and would remain unbounded on a paid plan	cl. 5.6
RTO (registry)	4 hours (MCC-800 art. 21 and art. 92(a); MCC-850 art. 12)	Unbounded and untested. There is no standby replica to fail over to, no restore path the Programme controls, and no rehearsed procedure	cl. 3.5, 5.2, 9.2
Archive retrievability	48 hours (MCC-800 art. 88)	Not applicable. No archive exists; MCC-810 is a draft and cl. 18.2 of MCC-800 v2.0-draft would forbid destroying any record until it is in force	—
Geographic redundancy	Required (MCC-100 cl. 0218; MCC-800 art. 88)	Absent. Both tiers are in Stockholm	cl. 3.5
Uptime	99.5% / 99.9% (conflicting, cl. 2.2.1)	Not measured against any objective. sla_measurements held 572 rows and system_health_check 5,110 on 4 September 2026 (1,218 and 13,508 on 1 October 2026), but neither is reconciled to a published availability figure	cl. 2.2.1

5.9 The Programme SHALL NOT state, publish or represent to any applicant, VVB, buyer, host country or counterparty that it meets the recovery objectives of MCC-800 art. 21, MCC-CADCP cl. 0144 or MCC-850 art. 12 until Section 6 is implemented and Section 9 has been exercised at least once. A representation of recovery capability is a representation about the safety of other people's entitlements.

5.10 The External Institutional Launch Pack v1.0 states, under "Backup and Disaster Recovery", "Automated backups with Recovery Point Objective (RPO) of 1 hour" and "Recovery Time Objective (RTO) of 4 hours", and an "Availability Target: Minimum 99.5% uptime measured on rolling 30-day basis". Read against clause 5.8, those statements are not true of the deployed system. The Launch Pack has been withdrawn: the Programme Factsheet, adopted under FD-2026-08-24 (recorded in the decision register as attested by the founder; no executed copy filed), replaces it as the Programme's only external institutional summary and records it as withdrawn.

---

6. Proposed recovery objectives

6.1 Recovery objectives are commitments the Governing Board makes. This Plan does not set them. It proposes them, and every figure below is open until the Board decides it.

6.2 The recovery point objective for registry data is for the Governing Board to set. Proposed: 24 hours before first issuance; 1 hour from the day issuance is enabled. (Consultation question 2.) The rationale is that RPO 1 hour requires Point-in-Time Recovery (cl. 5.3), PITR requires a paid plan and a compute add-on, and there is nothing yet in the registry whose loss would be irreversible. A daily off-site export (cl. 6.6) reaches 24 hours at negligible cost and closes the unbounded exposure immediately.

6.3 The recovery time objective for the registry is for the Governing Board to set. Proposed: 24 hours before first issuance; 4 hours from the day issuance is enabled. (Consultation question 3.) RTO 4 hours as written in MCC-800 art. 92(a) presupposes "automated database failover to a standby replica", which does not exist and cannot exist on the free plan. An honest 24-hour objective that is rehearsed is worth more than a 4-hour objective that is aspirational.

6.4 The recovery point and time objectives for object storage are for the Governing Board to set. Proposed: RPO 24 hours, RTO 24 hours, from adoption. (Consultation question 4.) Storage needs its own export regardless of plan (cl. 5.6), and no in-force clause distinguishes it, so the Board is deciding this for the first time.

6.5 The availability objective, and the resolution of the 99.5% / 99.9% / 99.9%-in-business-hours conflict at cl. 2.2.1, are for the Governing Board to decide. Proposed: a single figure, stated once, in whichever instrument survives the MCC-800 v2.0 rewrite, and measured by a probe whose output is published. This Plan takes no position on the number. (Consultation question 5.)

6.6 FD-2026-09-04 item 5 (recorded in the decision register as attested by the founder; no executed copy filed) resolved that a database plan including daily backups and point-in-time recovery be procured immediately, and that an off-site export of the database and of object storage be established, the date each is first achieved being recorded and reported to the Board; no tested backup is recorded in the programme record. The dependency is unavoidable and is stated plainly so it can be priced: RPO 1 hour requires a paid Supabase plan plus the PITR add-on plus a compute add-on. Nothing else on this list requires a plan change — a scheduled logical export of the database and of the three storage buckets to an independently controlled destination can be built on the free plan and would move the RPO from unbounded to 24 hours. The destination for off-site exports is not named in this Plan; it must be an account the Programme controls and which is not the Supabase or Vercel account, so that a compromise or closure of either does not take the backups with it. (Consultation question 6.)

6.7 Until the Board decides clauses 6.2 to 6.6, the objectives in force remain those at clause 2.1 and the Programme remains in breach of them. This Plan does not cure the breach; it records it so that it can be cured deliberately.

---

7. Failure scenarios

7.1 Each scenario below is one that this architecture can actually produce. Speculative scenarios have been omitted. For each: what it looks like, what is done now, and what is missing.

7.2 F1 — Provider outage (Vercel or Supabase). The application or the database becomes unreachable while the data remains intact.

7.2.1 Detection: partly automatic. The watchdog (cl. 5.5) writes to system_health_check hourly and returns a non-2xx status on critical failure so that the Vercel cron log itself turns red. A Supabase outage would also break the watchdog's own writes, in which case the signal is the absence of new rows. Whether an external uptime probe, independent of both providers, is commissioned is not decided — no probe outside the platform measures availability; the only external check is a nightly browser-test run against production (.github/workflows/e2e.yml). (Consultation question 7.)

7.2.2 Response: there is none to execute. There is no standby replica (MCC-800 art. 92(a)), no second availability zone (art. 92(b)) and no secondary hosting environment for DNS failover (art. 92(c)). The Programme's response to a provider outage is to wait for the provider and to discharge the notification duties at Section 9.

7.2.3 The duties at MCC-800 art. 93 attach once the outage exceeds 1 hour, and they are performable without any technical recovery capability. They are the part of art. 91–94 the Programme can comply with today, and it SHALL.

7.3 F2 — Loss or corruption of the database. The Supabase project is lost, or its data is corrupted at rest.

7.3.1 This is the scenario the free plan does not survive. Per clause 5.2 there is no dashboard-accessible restore, per clause 5.4 there is no export of the Programme's own, and per clause 5.6 the storage buckets would not be recovered even if the rows were.

7.3.2 Recovery today would consist of: rebuilding the schema from the migration history in the repository, and re-entering by hand whatever can be reconstructed from correspondence and from the two project submissions. The audit trail (247 entries on 1 October 2026) and the human-decision records (5) would not be reconstructible; they are, by design, the records of what was decided and by whom.

7.3.3 The mitigation is clause 6.6 and nothing else. No procedure written in this Plan substitutes for a backup that exists.

7.4 F3 — Credential compromise. A key or credential is disclosed, guessed or leaked.

7.4.1 The credentials that matter are: the Supabase service-role key (which bypasses row-level security entirely), CRON_SECRET (which authorises every scheduled function), the Supabase database password, the Vercel account itself (which holds every other secret in its environment configuration), and the third-party keys at clause 3.6 — including the Anthropic API key.

7.4.2 A compromise of the Vercel account is a compromise of every credential at once, because that is where they all live. There is no separate secret store. Whether secrets are moved to a dedicated secret manager, and whether the Supabase service-role key is rotated on a schedule rather than only on suspicion, is not decided. (Consultation question 8.)

7.4.3 Response: revoke and rotate; then determine, from audit_log_entries (which records actor, role, IP address, user agent, previous and new state) what was done with the credential. That table is the Programme's only forensic record, which is itself an argument for clause 6.6 — an attacker with the service-role key can write to it.

7.4.4 A credential compromise affecting personal data is also a personal-data breach and is handled under the Information Security Standard (MCC-ISS v1.0-draft §11) and, on adoption, MCC-850 v2.0-draft cl. 15.6. This Plan does not restate those duties.

7.5 F4 — Accidental deletion or destructive change. A migration, a script or a hand-run statement deletes or overwrites data that was correct.

7.5.1 This is the scenario Point-in-Time Recovery exists for, and PITR is unavailable (cl. 5.3). A daily export (cl. 6.6) bounds the loss at one day; it does not prevent it.

7.5.2 Two partial controls exist and are recorded because they are real. registry-reconciliation-nightly runs in the database at 02:45 UTC and checks serial uniqueness and format, demonstration-flag agreement, unit and batch vintage, issuance-request linkage, buffer units and ledger, retirement sums and holdings; the watchdog fails critically if no reconciliation run has been recorded in 26 hours. The hourly batch_unit_arithmetic check independently asserts that per batch, holdings equal ACTIVE+BUFFER units and that ACTIVE+BUFFER+RETIRED equals the batch's declared total. Both detect an arithmetic inconsistency. Neither reverses one.

7.5.3 Deletion of the Supabase project itself is the extreme case of this scenario and is irreversible (cl. 5.7). The control is access to the Supabase dashboard, not backup. Who holds Supabase and Vercel account access, whether those accounts have multi-factor authentication enabled, and whether more than one person can reach them is not stated in this Plan; a single-holder account is also a continuity risk if that person is unavailable. (Consultation question 9.)

7.6 F5 — Dependency failure. A third party at clause 3.6 becomes unavailable, unauthenticated or rate-limited.

7.6.1 The model provider is the only dependency with a governed failure mode, and it is well governed. MCC-850 art. 12.1 provides that where the provider "is unavailable, unauthenticated, rate-limited or fails to return a valid response within the configured timeout", the platform may produce a deterministic heuristic in place of a model analysis; art. 12.1.1 to 12.1.5 require that record to be labelled, capped at LOW confidence, barred from recommending APPROVE, excluded from prioritised sequencing and excluded from calibration. Art. 12.1.6 makes continuous Degraded Mode beyond twenty-four hours an incident. The watchdog implements the detection: it fails critically where every AI review in the last 24 hours used heuristic-fallback-v1.

7.6.2 Mail is the dependency with the worst history and the best instrumentation. The watchdog asserts, each run, that the Resend credential is accepted by the provider and that no notification is refused, stuck PENDING beyond an hour, or abandoned as FAILED in 24 hours; separately it probes Supabase Auth's own mailer, because that is a different sender and a green Resend check says nothing about account confirmation or password reset. Both checks are CRITICAL, save that since 1 October 2026 a mail provider that cannot be reached is reported as a WARNING until it has been unreachable on three consecutive runs, or at once if the queue shows mail refused, stuck or abandoned (PR #366).

7.6.3 The remaining dependencies have no governed failure mode and no fallback: NatureMetrics (eDNA), Planet, Sentinel Hub and Spire (monitoring imagery and vessel data), and Sentry (error reporting). No upload is scanned for malware: the ClamAV validator that read MALWARE_SCAN_DISABLED and MALWARE_SCAN_REQUIRED was removed with the retired packages on 24 August 2026 (PR #118). Whether upload scanning is required in production, such that a scanner outage blocks uploads rather than permitting unscanned ones, is not decided. (Consultation question 10.)

7.6.4 No supplier register exists. MCC-ISS v1.0-draft cl. 12.4 would require one ("A register of suppliers and their assessments SHALL be maintained; a supplier failure SHALL be handled under Section 11 and the continuity plan"). Clause 3.6 of this Plan is the nearest thing the Programme has, and it was assembled from environment-variable references in the source. Recorded as a gap.

7.7 F6 — Loss of the ability to rebuild. The source repository or the deployment configuration becomes unavailable, so that even undamaged data cannot be served.

7.7.1 The application is reconstructible from the repository, and the schema from its migration history. The environment configuration is not in the repository — by design, since it holds secrets — and is therefore held only in the Vercel project. An inventory of environment-variable names, without their values, is kept in the repository at apps/web/.env.example; it does not list every variable the deployment reads (it omits, for example, the Sentry DSN). Whether the Plan should require that inventory to be kept complete, so that a rebuild does not have to be reverse-engineered from process.env references, is put to consultation. (Consultation question 11.)

---

8. Who declares an incident, and who decides to recover

8.1 This section names only bodies and roles that exist. Where the in-force instruments assign a duty to a body that has not been constituted, the duty is recorded as unassigned.

8.2 The Programme Administrator exists as an operational role and has two accounts on the platform, one of them active on 1 October 2026. Under MCC-850 art. 12.1.6 and art. 35 the Programme Administrator is the recipient of incident escalation. Proposed: the Programme Administrator declares an incident under this Plan, and is the incident owner until it is closed. Confirmation of that allocation, and of an alternate for when the Programme Administrator is unavailable, is put to consultation; no alternate is proposed, and a single named owner with no alternate is itself a continuity failure. (Consultation question 12.)

8.3 The Governing Board exists. It was constituted on 26 August 2026 by GB-2026-001 and the governance register records two appointments to it, both dated 26 August 2026: a transitional founder seat, and an independent chair. GB-2026-001 is recorded in the decision register as attested by the founder on 27 August 2026, with no executed copy filed. Proposed: the decision to invoke recovery in scenario F2 (loss of the database), and any decision to suspend registry operations, is the Governing Board's; every other recovery decision is the Programme Administrator's. The distinction is that F2 and suspension affect entitlements and public representations, and the others are operational.

8.4 The Registry Manager exists as a platform role, with two accounts, neither of them active on 1 October 2026. MCC-800 art. 93 and art. 94 place the outage-notification and post-incident-review duties on the Registry Manager by name, and this Plan does not move them.

8.5 The Registry Oversight Authority is named in MCC-700 v3.0 cl. 4.3.3 and is recorded in the platform's governance register as an epoch-1 body, but no person has been appointed to it. The quarterly review of "backup/disaster recovery procedures" that cl. 4.3.3 requires therefore has no one to perform it, and has never been performed. Gap recorded; duty not assigned. It is proposed that its functions are exercised by the Governing Board until it is constituted (FD-2026-10-01 Schedule 1, C5); the Governing Board decides on adoption. (Consultation question 13.)

8.6 The Technical Committee is named in MCC-850 art. 8, art. 10 and art. 26 as the recipient of recurring SLA breaches and the reviewer of override patterns. It does not appear in the platform's governance register at all, in either epoch, and no person has been appointed to it. Gap recorded; duty not assigned.

8.7 The Registry Operator is the addressee of MCC-800 art. 91 and art. 92, and of MCC-BPM cl. 0084. No separate legal entity has yet been incorporated for the Programme (FD-2026-10-01 item 3). The adopted Legal and Regulatory Positioning records that incorporation as a Norwegian aksjeselskap is "the founders' declared intention, not yet resolved by any board", and that "The platform is presently held under a Luxembourg-domiciled company as a transitional arrangement". There is therefore no Registry Operator in the sense MCC-800 uses the term, and the duties art. 91–92 place on it are, in law, placed on nobody. No entity is identified as the Registry Operator for the purposes of MCC-800 pending incorporation (FD-2026-10-01 item 3); the administration proposes that the operating entity be a Norwegian aksjeselskap (AS), whose name and jurisdiction the Governing Board decides. The registry continuity and wind-down plan that MCC-800 v2.0-draft cl. 21.1 would require is not attempted in this Plan. (Consultation question 14.)

8.8 The Registry Oversight Committee, the Programme Secretariat, the Independent Governing Board, the VVB Oversight Committee, the Standards Committee, the Safeguards and Rights Panel and the Independent Appeals Panel exist only in MCC-700 v4.0-draft, which is not in force, and none has any appointment recorded. This Plan assigns no duty to any of them. On adoption of MCC-700 v4.0 and MCC-800 v2.0, the allocations at clauses 8.2 to 8.4 SHALL be re-expressed against the bodies those instruments create.

---

9. Communication obligations

9.1 The communication duties on an outage are in force today and are performable today, whatever the state of the technical controls. They SHALL be performed.

9.2 On any unplanned outage exceeding one hour, the Registry Manager SHALL, under MCC-800 art. 93: notify all account holders of the outage and the expected restoration time; publish a status update on the MCC website; and suspend all pending workflow deadlines until service is restored.

9.3 Clause 9.2 has a dependency the Plan must name: notification to account holders travels by the same platform whose outage is being notified, and by the same mail provider the watchdog monitors. An outage of S1 or S4 disables the channel by which clause 9.2 would be discharged. An out-of-band notification route — a status page hosted outside Vercel, or a mailing route that does not depend on the platform — is proposed, so that the duty at art. 93(a) and (b) can be discharged during the event it exists for. (Consultation question 15.)

9.4 Following any unplanned outage, the Registry Manager SHALL conduct a post-incident review within 10 business days and publish a summary of findings, root cause and remediation actions (MCC-800 art. 94; restated at MCC-800 v2.0-draft cl. 20.6 and MCC-ISS v1.0-draft cl. 11.5).

9.5 What is published is constrained by the Transparency Policy, and the constraint cuts both ways. Article 3(4) withholds "Backup and disaster recovery procedures" from publication as Security Information, alongside "System vulnerabilities (until patched)" and "Account security procedures". Article 3(4) does not authorise withholding the fact of an outage, its duration, its cause or its consequences, and the Programme SHALL NOT read it to do so: art. 94 requires the root cause and remediation to be published, and Article 1 of the Transparency Policy states the governing principle that "Except where legitimate confidentiality applies, MCC publishes."

9.6 Where an incident affects the AI Analysis Layer, the disclosure obligations of the Transparency Policy §2.6 and of MCC-850 art. 30 apply in addition, and Degraded Mode operation is separately labelled to staff and applicants on every surface on which the analysis appears (MCC-850 art. 12.1.1).

9.7 Where an incident involves personal data, the notification duties are those of applicable data protection law and of the Information Security Standard, and are not stated in this Plan. See clause 11.3 and DPIA-2026-001.

---

10. Testing

10.1 No disaster recovery test has ever been run. No failover exercise, no restoration test, no tabletop exercise appears anywhere in the programme record, in the repository, or in the platform's own records. MCC-800 art. 91 has required an annual simulated failover exercise since 1 April 2026 and MCC-850 art. 12 has required quarterly testing of the disaster recovery plan; neither has been performed, and until this draft there was no plan to test.

10.2 A test is only meaningful once there is something to restore from. The sequence below is therefore ordered as a dependency chain, not as a calendar.

#	Exercise	Prerequisite	Proposed cadence	Evidence produced
T1	Restore a database export into a scratch project and verify row counts and referential integrity against the source	An export exists (cl. 6.6)	Quarterly, and before issuance is first enabled	Restore log, count comparison, elapsed time measured against the RTO at cl. 6.3
T2	Restore the three storage buckets from export and verify object count and checksums against documents.checksumSha256	A storage export exists (cl. 6.4)	Quarterly	Object count and checksum comparison
T3	Credential rotation drill: rotate the Supabase service-role key and CRON_SECRET and confirm every scheduled function recovers	None	Annually	Watchdog output before, during and after
T4	Tabletop on F2 (loss of the database), with the Programme Administrator and the Governing Board seat holders	Section 8 allocations confirmed	Annually	Minute recording the decisions taken and the time they took
T5	Dependency-failure drill: revoke the model provider key in a non-production context and confirm Degraded Mode labelling, the LOW confidence ceiling, the APPROVE floor and the 24-hour escalation of MCC-850 art. 12.1	None	Annually	AI review record and watchdog output

10.3 Each exercise SHALL produce a dated record stating what was attempted, what was achieved, the elapsed time, and every objective at Section 6 that was and was not met. A test that produces no record has not been performed.

10.4 The cadence at clause 10.2 is proposed at quarterly for T1 and T2 and annually for the rest, which resolves the art. 91 / art. 12 conflict at clause 2.2.2 in favour of the stricter reading for the exercises that matter most. The cadence is the Board's to decide. (Consultation question 16.)

10.5 The first exercise SHALL be run before issuance is first enabled, and its outcome recorded, alongside the independent penetration test that MCC-800 v2.0-draft cl. 19.4 would require on the same trigger.

---

11. Relationship to the Information Security Standard (MCC-820)

11.1 MCC-ISS (MCC-820) v1.0-draft is published as a companion consultation draft. Its clause 15.1 provides that "Backup, disaster recovery and business continuity for the registry are governed by MCC-800 Section 20 under this Standard's protections (encrypted, integrity-verified, geographically redundant backups; at least annual restoration and failover testing); recovery-objective values are recorded in the Registry Architecture Specification."

11.2 The division this Plan adopts, so that the two instruments do not overlap:

Question	Answered by
How is a backup protected — encryption, integrity verification, key management, access	MCC-ISS §6 and §15.1
Where does a backup go, how often, and how far back does it reach	This Plan, Sections 5 and 6
How is an incident classified, escalated, and its evidence preserved	MCC-ISS §11
Who declares a continuity incident and who decides to recover	This Plan, Section 8
What is communicated on an outage, to whom, and by when	This Plan, Section 9, applying MCC-800 art. 93–94
Whether a supplier is fit to hold Programme data	MCC-ISS §12
What happens operationally when a supplier fails	This Plan, clause 7.6
How long a record is kept and when it is destroyed	MCC-810 Record Retention Schedule
Security testing, including penetration testing	MCC-ISS §9
Restoration and failover testing	This Plan, Section 10

11.3 This Plan states no encryption algorithm, key length, protocol version or authentication technology, consistent with MCC-800 v2.0-draft cl. 19.2. Where a control of that kind is needed to protect a backup, it traces to MCC-ISS §6.

11.4 A personal-data breach is a security incident and a data-protection event. This Plan handles neither. Security incidents are MCC-ISS §11; personal-data consequences are the Privacy Policy's (MCC-PRIV v1.0-draft, published as a companion consultation draft and not in force) and DPIA-2026-001's. On adoption, MCC-850 v2.0-draft cl. 15.6 would route personal-data breaches involving AI systems through that Standard's §19.

11.5 MCC-ISS v1.0-draft cl. 15.2 would additionally require continuity arrangements for Programme systems other than the registry, "documented proportionately to criticality and tested at least annually". This Plan does not cover corporate systems, the founder's own devices, or any store of Programme records outside the platform. Gap recorded.

---

12. Review, amendment and entry into force

12.1 This Plan is not in force and sets no objective. It enters into force only on adoption by the Governing Board, and no earlier than the date the Board fixes.

12.2 On entry into force this Plan SHALL be reviewed at least annually, and additionally: after any incident to which it was applied; after any exercise under Section 10 that failed to meet an objective; on any change to the hosting arrangements, the subscription plan or the region of either tier; and on the entry into force of MCC-800 v2.0, MCC-ISS or the Registry Architecture Specification.

12.3 Where MCC-800 v2.0 enters into force, the recovery-objective values at Section 6 SHALL be transferred to the Registry Architecture Specification under cl. 1.6 and 20.2 of that draft, and this Plan SHALL cite them rather than restate them.

---

Annex — What the Board must decide

#	Question	Proposal on the table
1	Resolve the availability conflict: 99.5% (MCC-800 art. 18) against 99.9% (MCC-100 cl. 0219) against 99.9% in business hours (MCC-850 art. 12) — and whether, and from what date, the Pilot Phase relaxation at MCC-800 art. 107 applies (GB-2026-001 resolution 1.3 records the Pilot Phase under MCC-700 §10.1 as beginning on 26 August 2026)	One figure, stated once, measured and published
2	Resolve the test-cadence conflict: annually (MCC-800 art. 91) against quarterly (MCC-850 art. 12)	Quarterly for restore tests, annually for the rest (cl. 10.4)
3	The recovery point objective for registry data	24 hours now; 1 hour from first issuance (cl. 6.2)
4	The recovery time objective for the registry	24 hours now; 4 hours from first issuance (cl. 6.3)
5	The recovery objectives for object storage, which no instrument presently addresses	RPO 24 hours, RTO 24 hours (cl. 6.4)
6	Whether to authorise a paid Supabase plan with the PITR and compute add-ons — without which RPO 1 hour is unattainable	FD-2026-09-04 item 5 (attested; no executed copy filed) resolved that it be procured; no tested backup is recorded (cl. 5.3, 6.6)
7	Whether to authorise a scheduled off-site export of database and storage to a destination the Programme controls and that is not the Supabase or Vercel account	FD-2026-09-04 item 5 (attested; no executed copy filed) resolved that it be established; the destination is put to consultation (cl. 6.6)
8	Who declares an incident, who owns it, and who the alternate is	Programme Administrator declares and owns; Governing Board decides F2 and suspension (cl. 8.2–8.3)
9	The Registry Oversight Authority: appoint to it, or expressly vest its cl. 4.3.3 review in the Governing Board	Presently unappointed; the quarterly DR review has never been performed (cl. 8.5)
10	Who is the Registry Operator for MCC-800 art. 91–92 purposes pending incorporation	No entity is incorporated; the duty rests on nobody (cl. 8.7)
11	An out-of-band status and notification route, so art. 93 can be discharged during the outage it addresses	Required; presently the channel fails with the system (cl. 9.3)
12	Whether the External Institutional Launch Pack's backup, RPO, RTO and availability statements are withdrawn or corrected	Answered: the Launch Pack is withdrawn and replaced by the Programme Factsheet (cl. 5.10)
13	Disposal of infrastructure/terraform/, which describes an AWS architecture that was never built	Delete, or move and label as unbuilt (cl. 3.8)
14	Whether malware scanning is required in production, such that a scanner outage blocks uploads	No upload scanning exists; the ClamAV validator was removed on 24 August 2026 (cl. 7.6.3)

Fourteen items: items 6, 7 and 12 are addressed at clauses 6.6 and 5.10, and the rest are put as consultation questions above. Until they are decided, the honest answer to "what happens if we lose the database?" is the one at clause 7.3.2.

---

Prepared 4 September 2026 for public consultation. Evidence: the 34 in-force texts in the review corpus, in particular MCC-800 v1.0 art. 14, 18–21, 88, 91–94 and 107, MCC-100 v2.1 cl. 0218–0219, MCC-850 v1.1 art. 8, 10, 12, 12.1 and 26, MCC-CADCP v1.0 cl. 0144, MCC-BPM v1.0 cl. 0084, MCC-700 v3.0 cl. 4.3.3, the Transparency Policy v1.1 art. 1, 2.6, 3(4) and 4.1–4.2, and the External Institutional Launch Pack v1.0; the adopted content set, in particular the Legal and Regulatory Positioning note on incorporation; the consultation drafts MCC-800 v2.0-draft §1.6, 18, 19, 20 and 21, MCC-ISS (MCC-820) v1.0-draft §11, 12 and 15, MCC-810 v1.0-draft and MCC-850 v2.0-draft §15 and 19; the Supabase project ifflkkpowmzjoochwavf interrogated by read-only SQL on 4 September 2026 — region eu-north-1, PostgreSQL 17.6, organisation subscription plan free, 78 public tables, three storage buckets, two pg_cron jobs, zero credit units and two projects; Supabase's published backup, Point-in-Time Recovery and project-deletion documentation; and the codebase at apps/web/src — vercel.json, app/api/monitoring/cron-watchdog/route.ts, lib/ai/run-review.ts, infrastructure/terraform/main.tf, .github/workflows/ and scripts/ — searched on the same date, which contains no backup or restore procedure of any kind. No decision in this draft has been taken, and no recovery objective in it is set.