MCC-RRS — Record Retention Schedule

Document control

Field	Value
Document code	MCC-810, proposed as its register code in place of the working code MCC-RRS used in this draft (FD-2026-10-01 Schedule 1, Q22) (Consultation question 1.)
Title	Record Retention Schedule
Version	1.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	3 September 2026
Tier	Tier 5 (Document Hierarchy & Precedence Register, per FD-2026-09-03 item D5 — the register lists this Schedule among the Tier 5 controlled artefacts; it is also canonical Phase 1 control register 9 per audit §8, so higher-tier documents cite it rather than restating retention rules)
Effective date	None. This document is not in force.
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	Audit finding SYS-11 (required correction: "Create a Record Retention Schedule … Policies should reference the canonical controls"); FD-2026-09-03 items D1–D8 context. This is a new document: no predecessor exists; the suite previously scattered at least nine conflicting retention rules across six documents (Section 3).
Supersedes	None (new document). On entry into force it supersedes every local retention figure in the superseded corpus texts, whose removal the rewritten suite has already effected.
Language convention	British English; RFC-style normative verbs; one requirement per numbered clause.
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 document is issued for public consultation. Nothing in it asserts that any record, system or approval exists unless a linked record is identified in the MCC Evidence Register. The interim rule of the rewritten suite — that no record is destroyed until the Record Retention Schedule is in force (MCC-700 v4.0-draft clause 21.2; MCC-100 v3.0-draft clause 20.9; MCC-BPM v2.0-draft clause 15.3; MCC-800 v2.0-draft clause 18.2) — is proposed in those consultation drafts and, like them, is not in force.

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. Document control — register code. Proposed: MCC-810, in place of the working code MCC-RRS, keeping the 800-series for registry operations. Basis: FD-2026-10-01 Schedule 1 (Q22); FDP-2026-001 Q22. Decided by: the Governing Board on adoption of the suite. Comments are invited on the code.

2. Clause 2.1 and class R12 — statutory retention minima. Proposed: no figure is proposed — the minima depend on the jurisdiction of the Programme's operating entity, which has not yet been incorporated. The administration proposes that the entity be a Norwegian aksjeselskap (AS); once its jurisdiction is fixed, any statutory period longer than a period in Section 2 prevails and is recorded in this Schedule. Basis: FD-2026-10-01 item 3 and Schedule 1 (C1). 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, recorded in the decision register as attested by the founder, with no executed copy filed). Comments are invited on whether the periods in Section 2, including the 7-year period for class R12, are adequate pending incorporation.

1. Purpose, scope and application

1.1 This Schedule is the single canonical source of record retention, access, disposition and legal-hold rules for the MCC Programme, reserved to it by MCC-001 clause 10.8; no other Programme document SHALL state a retention period. A conflicting statement in a document of a tier lower than this Schedule is void to the extent of the conflict once this Schedule is in force; a conflict with a higher-tier document is resolved under MCC-001 Section 2, and this Schedule is read down to conform.

1.2 This Schedule applies to every record created, received or held by the Programme, the Legal Entity, the Registry Operator and — through participation agreements and MCC-400 — VVBs and participants, in whatever medium.

1.3 Every record SHALL belong to exactly one record class of Section 2; a record type not listed SHALL be assigned to a class by the document owner, recorded in the next revision, and treated meanwhile under the closest listed class, choosing the longer retention where in doubt.

1.3.1 For the avoidance of doubt, two record types that previously rode the clause 1.3 catch-all are assigned expressly: methodology development records and methodology dossiers (MCC-200 clause 6.9) belong to class R6; cross-programme double-counting check records (MCC-CADCP clause 6.8) belong to class R5.

1.4 Retention periods are minimums; a record MAY be retained longer only where a documented lawful basis exists, and indefinite retention "just in case" is prohibited (data minimisation).

2. The Schedule

2.1 Records SHALL be retained, accessed and dispositioned per the following table. "EOL trigger" is the event starting the retention clock. Lawful bases are stated generically; the operative basis per jurisdiction is confirmed in the privacy documentation of MCC-800 Section 18. The statutory retention minima that will apply depend on the Legal Entity's jurisdiction, and the Programme's operating entity has not yet been incorporated (FD-2026-10-01 item 3); any statutory period exceeding a period below prevails and is to be recorded here once that jurisdiction is fixed. (Consultation question 2.)

#	Record class	Owner	Purpose and lawful basis	EOL trigger	Retention period	Access	Disposition
R1	Registry unit and transaction records: units, batches, serial ranges, issuance/transfer/retirement/cancellation records, buffer accounting, retirement certificates, Article 6 attributes with evidence references, Family-Map Register	Registry Operator (Registry Oversight Committee oversight)	Registry integrity; permanence of claims; legitimate interest/contract	n/a	Permanent (life of the Programme and any successor or escrow arrangement, per MCC-800 Section 21)	Public per MCC-100 Section 20; full record: registry function, auditors	Never destroyed; archived; personal data excluded by design (MCC-800 clause 18.4)
R2	Registry audit trail	Registry Operator	Integrity evidence for R1; security forensics; legitimate interest	Creation of the audit record	As long as the record it evidences, minimum 20 years	Registry function, auditors, competent authorities on lawful request	Secure destruction after expiry where the evidenced record is itself expired; else retained with it
R3	Account, KYC/KYB/UBO and sanctions-screening records; onboarding determinations; representative identity records	Registry Operator	AML/CFT-aligned due diligence; contract; legal obligation where applicable	Account closure (or final refusal of an application)	10 years	Registry function (need-to-know), compliance monitoring, auditors, competent authorities on lawful request	Secure destruction; erasure requests honoured after expiry only
R4	Validation and verification records: VVB reports, working papers, evidence files, sampling records	VVB (duplicate lodged with Programme per MCC-400)	Evidence base of issued units; legitimate interest/contract	End of the crediting period of the project concerned	10 years after the EOL trigger, and never less than 10 years from report issue	Programme, VVB oversight, auditors; report conclusions public per MCC-100	Secure destruction after expiry
R5	Project records: PDDs, monitoring reports, safeguards assessments, grievance records, consultation records, host-country instruments, risk assessments	Programme Secretariat	Evidence base of registration and issuance; remedy survival; legitimate interest/contract	End of the crediting period, or — for projects with a durability commitment — end of the enforceable durability and reversal-monitoring commitment, whichever is later	10 years after the EOL trigger	Programme, auditors; public subset per MCC-100 Section 20 and the ESS Policy	Secure destruction after expiry; grievance records containing personal data minimised at resolution + 10 years
R6	Governance records: decisions, decision register, minutes, voting records, conflict declarations, appeals and complaints files, the Evidence Register, adopted control tables and consultation records for adopted instruments	Programme Secretariat (per MCC-700 Section 21)	Constitutional and accountability record; legitimate interest	n/a	Permanent	Published subset per MCC-700 Section 21; full record: governance bodies, auditors	Never destroyed; personal data in complaint/appeal files minimised 10 years after closure
R7a	AI system decision-support records: outputs, prompts/inputs, logs, reason codes, human-review records for a specific Programme decision	AI system owner (per MCC-850 as reissued)	Evidence for the decision they informed; accountability; legitimate interest	The EOL trigger of the decision's own record class (R4, R5 or R6)	Same as the record class of the decision they informed	Decision participants, oversight bodies, auditors, appellants per MCC-700	Destroyed with the decision record; never retained beyond it
R7b	AI model documentation: model/version logs, dataset cards, validation and bias-test reports	AI system owner	Model accountability and audit; legitimate interest	Retirement of the model version	10 years	Oversight bodies, auditors; published summaries per MCC-850	Secure destruction after expiry
R8	Workflow and process records (completed registry/platform workflow instances not within R1)	Registry Operator	Operational accountability; legitimate interest	Workflow completion	10 years	Registry function, auditors	Secure destruction
R9	Notification and communication logs	Registry Operator	Delivery evidence; legitimate interest	Dispatch	5 years	Registry function	Secure destruction
R10	Security, system and API access logs	Registry Operator	Security monitoring; legitimate interest	Log creation	2 years, except extracts preserved under R11 or legal hold	Security function, auditors	Secure destruction; automated rotation
R11	Security incident and investigation records (including preserved log extracts)	Security owner (Information Security Standard Section 3)	Incident accountability; legal defence; legitimate interest	Incident closure	10 years	Security function, Registry Oversight Committee, auditors	Secure destruction
R12	Financial and fee records	Legal Entity	Accounting; legal obligation	End of the financial year concerned	7 years, or the statutory period of the Legal Entity's jurisdiction if longer — that jurisdiction depends on incorporation, which has not yet occurred (Consultation question 2.)	Finance function, auditors, authorities	Secure destruction
R13	Personnel, contractor and access-administration records (role grants, terminations, training)	Programme Secretariat	Employment/contract administration; access accountability	End of the person's access or engagement	6 years	HR/security function (need-to-know), auditors	Secure destruction
R14	Superseded controlled documents (withdrawn corpus texts, prior versions)	Document owner per the Document Register	Historical record; interpretation of past acts	Supersession	Permanent (archived, watermarked "SUPERSEDED", uncontrolled)	Public where the original was public	Never destroyed

3. Conflicts resolved (normative resolution record)

3.1 The following pre-existing conflicts are resolved by Section 2, deliberately and with these reasons; the superseded figures SHALL NOT be reapplied:

Conflict in the superseded corpus	Resolution	Reason
VVB records: 7 years (MCC-400 Art. 71) vs 10 years (MCC-100 v2.2 cl. 0157)	R4: crediting period + 10 years, ≥10 years from report	Verification evidence must outlive the units it supports, which are claimed long after the engagement; a 7-year accounting convention is too short for a multi-decade instrument. The longer, event-anchored period prevails. MCC-400 v2.0 MUST conform
Registry: audit trail 20 years (MCC-800 v1.x Art. 67/table) vs account records 10 years (Art. 38) vs "credit unit records permanent" (table) — cited in SYS-11 with incorrect article numbers, corrected in Phase 0	R1 permanent; R2 evidenced-record-linked ≥20 years; R3 10 years	The three figures governed three different classes and were never a single conflict; the Schedule keeps each, but ties the audit trail to the life of what it evidences so unit-record audit history can never expire before the unit record
AI records: "minimum 10 years; permanent retention recommended" (MCC-850 Art. 20) and "version history retained permanently" (Art. 11) vs data minimisation	R7a decision-linked; R7b model retirement + 10 years; permanence rejected	Per SYS-11: permanent AI retention collides with data minimisation. The durable artefact is the decision record (R4/R5/R6); AI material that informed it lives exactly as long, and model documentation has a bounded accountability life. MCC-850 v2.0 MUST conform
Buffer Policy: 10 years beyond crediting period (cl. 0031) vs crediting period + 15 years (cl. 0067) vs access logs 7 years (cl. 0170)	R5 (crediting/durability + 10 years); R10 (2 years)	The record must outlive the liability, which for durability-committed projects is the enforceable commitment period — an event anchor, not a flat figure; the flat 15-year tail is replaced by the longer-of rule in R5's trigger. Access logs are high-volume, personal-data-bearing and have no integrity function: the short period wins (see next row)
Access/API logs: 2 years (MCC-800 v1.x table) vs 7 years (Buffer cl. 0170)	R10: 2 years, with incident extracts preserved under R11	Minimisation: routine logs are kept short; anything evidentially significant is deliberately preserved into R11 (10 years) or under legal hold, which is the control that actually protects investigations
MCC-100 v2.2 local figures: LoA documents 7 years (cl. 0119); AI audit trails 7 years (cl. 0266); MCC-700 v3.1 governance records 7 years (cl. 14.2); notification 5 years, workflow 10 years (MCC-800 v1.x table)	R5, R7a, R6 (permanent), R9 (5 years kept), R8 (10 years kept)	Host-country instruments are project evidence (R5), not a 7-year class; AI trails follow their decisions (R7a); governance records are the Programme's constitutional memory and are permanent (R6); the uncontroversial 5- and 10-year operational figures are carried unchanged

4. General rules

4.1 Legal hold. On notice of litigation, investigation, audit, appeal or regulatory action, the document owner SHALL place a legal hold on all potentially relevant records; a held record SHALL NOT be destroyed, altered or minimised while the hold stands, whatever its retention expiry, and holds and their release SHALL be recorded.

4.2 Disposition. Destruction at expiry SHALL be performed securely and irreversibly across all copies and backups within the backup cycle, recorded in a disposition log (class, description, authorisation, date, method); the disposition log itself is an R6 record.

4.3 Data-subject rights. Access, rectification and erasure requests SHALL be honoured per applicable law; where a record must be retained under this Schedule, erasure SHALL be effected by minimisation or de-identification of the personal data within the record where that is compatible with the record's integrity purpose, and otherwise deferred to expiry with the data subject informed of the basis.

4.4 Permanent classes and personal data. Classes R1, R6 and R14 SHALL be designed to exclude personal data or to hold it only in severable form (MCC-800 clause 18.4), so that permanence never forces permanent personal-data retention.

4.5 Wind-down. On Programme wind-down, R1, R2, R6 and R14 records SHALL pass to the successor, escrow or independent host per MCC-800 Section 21 with this Schedule's obligations attached; other classes SHALL be retained to expiry by the Legal Entity or its administrator.

4.6 Review. This Schedule SHALL be reviewed at least annually and on any change of applicable law; review outcomes and any class changes SHALL be recorded through the amendment route of clause 5.1.

4.7 Each document owner SHALL verify annually that records in their scope are classified, retained and dispositioned per this Schedule, and file the confirmation in the Evidence Register (audit acceptance test QA-17).

5. Amendments and entry into force

5.1 This Schedule MAY be amended through the Tier 5 amendment route of the Document Hierarchy & Precedence Register, PROVIDED that no amendment weakens a retention obligation that a higher-tier document relies on without that document's owner being consulted and the change recorded in the changelog.

5.2 This Schedule SHALL enter into force upon approval by the authority MCC-001 clause 12.3 fixes for Tier 5 instruments — during the transitional period, upon a Founder Decision recorded and tabled for ratification under MCC-700 Section 23; until then, the retention periods stated in the instruments in force continue to apply, and the no-destruction interim rules of the rewritten suite take effect only with the drafts that carry them.

5.3 On entry into force, existing records SHALL be classified into Section 2 within ninety days, with a classification report filed in the Evidence Register.

---

End of MCC-RRS version 1.0-draft. Status: DRAFT — FOR CONSULTATION. Not in force.