MCC-PRIV — Privacy Policy v1.0-draft

Document control

Field	Value
Document code	MCC-PRIV (code assigned by the programme administration for this consultation; entered in the Document Register on adoption)
Title	Privacy Policy
Version	1.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	4 September 2026
Tier	Tier 5 (operational policy). It is the instrument MCC-800 art. 90 names and has never had.
Effective date	None. This policy 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	MCC-800 v1.0 art. 88–90 (in force); Transparency and Public Disclosure Policy v1.1 art. 2.1F, 2.2, 2.5, 2.8, 2.10 and art. 3(1); Legal and Regulatory Positioning Statement v1.1 art. 5.1–5.3 (adopted FD-2026-08-24, recorded in the decision register as attested by the founder, with no executed copy filed; ratified as to substance by GB-2026-001 item 2); Applicant Terms v1.1 art. 8.3; Registry Terms v1.1 art. 8.1–8.2; VVB Terms v1.1 art. 12.2; MCC-850 v1.1 art. 39–42; MCC-700 v3.0 cl. 14.2–14.3; Buffer Pool Management Policy v1.0 cl. 0179; SDCF v1.0 cl. 0064. Consultation drafts relied on as cross-references only: MCC-800 v2.0-draft §18, MCC-810 (Record Retention Schedule), MCC-820 (Information Security Standard), MCC-850 v2.0-draft §15, MCC-100 v3.0-draft cl. 20.7 and 20.9, MCC-ESS v2.0-draft §24.
Supersedes	None as an instrument. It is intended to replace, on entry into force, the unversioned website privacy notice served at /privacy ("Interim notice — corrected 4 September 2026"), which is not an adopted instrument and is in no document register; the statements in it that this draft could not verify were corrected or removed on 4 September 2026 (Section 15).
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 system, control, appointment, assessment, agreement or approval exists unless it is identified here as verified. Points the Programme has not decided, or on which it proposes a rule for comment, are listed under Consultation questions below and marked in the text.

Two things must be said at the front.

First: a privacy notice already exists and is published. The platform serves a Privacy Policy at /privacy, headed "Interim notice — corrected 4 September 2026. Not an adopted instrument." It is a website notice, not an instrument: it is not in src/lib/documents/manifest.ts, carries no version, no effective date, no approval, and no owner. It is not what MCC-800 art. 90 means by "the MCC Privacy Policy", but it is live and it is what a data subject actually reads. Until 4 September 2026 several of its statements were not supported by anything in the programme record; they were corrected that day, and Section 15 records them. This draft does not pretend the notice is absent.

Second: the controller cannot be named. No legal entity operates the Programme. The Definitions Register amendment records the Legal Entity as NOT CONSTITUTED; the Legal and Regulatory Positioning Statement v1.1 art. 1.2 records the intended Norwegian aksjeselskap as "the founders' declared intention, not yet resolved by any board", with the platform "presently held under a Luxembourg-domiciled company as a transitional arrangement". A privacy policy whose first substantive statement is normally "who we are" cannot make that statement. Section 3 says so rather than inventing an answer.

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 2.2 — the privacy regime. Proposed: no proposal is made on whether the Programme commits to GDPR as its baseline irrespective of where the Legal Entity is incorporated, or applies whichever regime the entity's jurisdiction imposes — the Programme's operating entity has not yet been incorporated, and the two differ materially on breach deadlines, DPO thresholds and transfer mechanics. The administration proposes that the entity be a Norwegian aksjeselskap (AS); until the point is decided, the terms in clause 2.2 are read in the sense of the GDPR. Basis: FD-2026-10-01 item 3 and Schedule 1 (C1); Annex, B1. 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 which baseline the Programme should commit to.

2. Clauses 3.1 and 5.1 (P2) — the data controller. Proposed: no controller is named until the Programme's operating entity is incorporated, when clause 3.4 records it by amendment; the administration proposes that the entity be a Norwegian aksjeselskap (AS). Whether due diligence and sanctions screening (P2) rest on legal obligation or on legitimate interest follows from the entity's jurisdiction. Basis: FD-2026-10-01 item 3 and Schedule 1 (C1); Annex, F1 and F5. 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 the position this Policy takes before incorporation.

3. Clause 3.5 — data protection officer. Proposed: no proposal is made — whether the applicable law requires a data protection officer at the Programme's present scale depends on the jurisdiction of the operating entity, which has not yet been incorporated. Basis: Legal and Regulatory Positioning Statement v1.1 art. 5.2; FD-2026-10-01 item 3 and Schedule 1 (C1); Annex, F2. 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 whether the Programme should appoint a data protection officer whatever the legal threshold.

4. Clause 4.3 — hashing audit_log_entries.ipAddress. Proposed: hashing on write, as attestations.ipHash already is: it preserves the integrity purpose — proving two actions came from one origin — while removing the plain identifier, at an audit-integrity cost. Basis: the drafting proposal (Annex, B2); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether the privacy gain justifies the integrity cost.

5. Clause 4.7 — GBV/SEA/SH reports. Proposed: no proposal is made — no store for such reports exists, because no project has reached the stage that generates them, and building one is itself a decision to hold the data. Basis: Annex, B3; MCC-ESS v2.0-draft cl. 16.6, 16.7 and 24.4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether such reports should be held on the platform at all, or handled entirely off-platform under Safeguards & Rights Panel control.

6. Clause 6.6.1 — the project lead's contact details. Proposed: pending amendment, this Policy applies Transparency Policy art. 3(1): the project lead's name and a role-based organisational contact address are published, and a personal telephone number is not. No proposal is made as to which clause is amended — §2.1F to a role-based contact, or art. 3(1) to carve out the project lead. Basis: the drafting proposal (Annex, B4); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on which of the two clauses should be amended.

7. Clause 6.6.3 — minimum responses before a satisfaction average is published. Proposed: five independent responses. Basis: the drafting proposal (Annex, B6); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether five is the right minimum.

8. Clause 7.8 — internal review of a refused rights request. Proposed: no proposal is made — no instrument settles whether a privacy refusal is a programme decision that the Independent Appeals Panel would hear, and no member of that Panel has been appointed. Basis: Annex, B7; MCC-700 v4.0-draft cl. 4.10. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether a refusal should be reviewable internally, and by whom.

9. Clause 11.2 — security owner and privacy owner. Proposed: the Programme Administrator is the security owner, disclosed as such, until a Programme Secretariat exists. No proposal is made for the privacy owner: FD-2026-10-01 makes none, and none has been designated under MCC-800 v2.0-draft cl. 18.1. Basis: FD-2026-10-01 Schedule 1 (Q13); Annex, F3. Decided by: the Governing Board on adoption of the suite. Comments are invited on who should hold the privacy-owner role, and whether one function may hold both roles.

10. Clause 15.4 — a dedicated privacy address. Proposed: a dedicated address such as privacy@, separating rights requests from general enquiries in contact_submissions; until it exists, info@marineconservationcredits.com remains the rights-request route (clause 7.2). Basis: the drafting proposal (Annex, B8); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether a dedicated address is needed.

---

1. Purpose, scope and application

1.1 This Policy is the single canonical statement of how the MCC Programme processes personal data. It is the instrument MCC-800 v1.0 art. 90 requires, which provides that "[p]ersonal data of account representatives shall be processed in accordance with applicable data protection legislation and the MCC Privacy Policy", and which has been in force since 1 April 2026 (MCC-800 art. 107) against a document that did not exist.

1.2 This Policy applies to personal data processed by the Programme, the Legal Entity when constituted, the Registry Operator, and the platform at marineconservationcredits.com and its staging deployment — including the registry, the public website, the portal, notification and email delivery, error monitoring, and AI systems within MCC-850.

1.3 This Policy SHALL NOT state a security control parameter; those are reserved to the Information Security Standard (MCC-820 cl. 1.1). This Policy SHALL NOT state a retention period; those are reserved to the Record Retention Schedule (MCC-810 cl. 1.1). This Policy states who is processed about, why, on what basis, what is published, and what a data subject may demand.

1.4 Where this Policy and an instrument of a higher tier conflict, the higher-tier instrument prevails and this Policy is read down to conform.

1.5 This Policy binds VVBs and participants through the participation agreements and MCC-400; it does not displace a VVB's own obligations under VVB Terms v1.1 art. 12.2, which requires a VVB to "[c]omply with GDPR (if EU-based or processing EU personal data)" and to "[p]rotect personal data of community members".

2. Normative references and interpretation

2.1 The normative verb conventions of the MCC drafting standard apply: SHALL states a requirement, SHALL NOT a prohibition, SHOULD a recommendation, MAY a permission. Each numbered clause states one requirement. NOTE text is non-normative.

2.2 In this Policy, personal data, processing, controller, processor, data subject and special category data bear the meanings given by the data protection law applicable to the Legal Entity once its jurisdiction is fixed. Until then they are read in the sense of Regulation (EU) 2016/679 (GDPR), which the Legal and Regulatory Positioning Statement v1.1 art. 5.1 and the VVB Terms art. 12.2 already treat as the operative reference. Whether the Programme commits to GDPR as its baseline irrespective of where the Legal Entity is incorporated, or applies whichever regime the entity's jurisdiction imposes, is not decided, and the Programme's operating entity has not yet been incorporated (FD-2026-10-01 item 3). The two differ materially on breach deadlines, DPO thresholds and transfer mechanics. (Consultation question 1.)

2.3 A reference in this Policy to a document marked draft is a reference to a consultation draft that is not in force; it is cited for cross-reference and consistency, and creates no obligation until that document takes effect.

3. The controller, and why it cannot be named

3.1 The identity of the data controller for the processing described in this Policy is not yet determined: the Programme's operating entity has not yet been incorporated (FD-2026-10-01 item 3), so there is no legal name, jurisdiction of incorporation, company number or registered office to state (Consultation question 2.). No such entity exists today: the MCC-100 Definitions Register amendment (draft) cl. 3.2.2 records of the Legal Entity that "No separate legal entity has yet been incorporated for the Programme (FD-2026-10-01 item 3). NOT CONSTITUTED", and MCC-700 v4.0-draft cl. 2.1 would require that the operator's "jurisdiction of incorporation, company number, registered office and beneficial ownership SHALL be publicly disclosed before this Standard is approved".

3.2 The present corporate position, as recorded in the adopted Programme Factsheet and in the Legal and Regulatory Positioning Statement v1.1 art. 1.2, is that "[t]he platform is presently held under a Luxembourg-domiciled company as a transitional arrangement" and the intended structure is a Norwegian aksjeselskap. This Policy SHALL NOT name either as controller: the Luxembourg company's role is custodial and undocumented in the programme record, and the Norwegian AS does not exist.

3.3 Until clause 3.1 is resolved, the Programme SHALL NOT represent to any data subject, counterparty or authority that a particular entity is the controller, and SHALL disclose on request that the controller is undetermined.

3.4 The Programme SHALL, on incorporation of the Legal Entity, record the controller in this Policy by amendment under Section 16, and SHALL notify registered users of that amendment before it takes effect.

3.5 A data protection officer has not been appointed. The Legal and Regulatory Positioning Statement v1.1 art. 5.2 states the requirement — "Appoint Data Protection Officer (if EU-based or processing EU data at scale)" — as an MCC requirement, and no appointment is recorded anywhere in the programme record. No recorded and reasoned determination that the applicable law does not require one at the Programme's present scale exists either, and that law depends on the jurisdiction of the operating entity, which has not yet been incorporated (FD-2026-10-01 item 3). Until an appointment or such a determination exists, art. 5.2 is an unmet obligation of an adopted document. (Consultation question 3.)

3.6 Where a VVB, a proponent or a host-country authority determines its own purposes for personal data it receives from or through the Programme, it acts as a controller in its own right for that processing, and this Policy SHALL NOT be read as making the Programme responsible for it.

4. The personal data actually held

4.1 This Section describes the personal data the platform holds in fact, verified against the live database on 4 September 2026 by querying information_schema.columns for the public schema and counting rows. It is not a generic inventory and SHALL be maintained against the schema, not against a template.

4.2 The following table is the record of processing for the platform. Row counts are as at 4 September 2026 and are stated to show that most of these stores are empty: the Programme is pre-issuance and pre-operational, and the personal data it holds today is overwhelmingly that of its own staff and of people who filled in a contact form.

Store (table)	Personal data columns	Data subjects	Rows at 4 Sep 2026
users	email, passwordHash, firstName, lastName, role, organisationId, active, mfaEnabled, lastLoginAt	Portal and registry account users	16
auth.users, auth.sessions (Supabase Auth schema, outside public)	authentication identifiers, session records	Authenticated users	8 users; 90 sessions
userOrganisations	userId, organisationId, role	Users, as members of an organisation	0
organisations	registeredName, address, registrationNumber, country, website, kycStatus, kycNote, kycDeterminedById, kycCosignedById	Entity data; the kyc*ById columns identify the staff who decided	6
contact_submissions	name, email, subject, message	Members of the public who used the contact form	25
newsletter_signups	email, source	Subscribers	1
consultation_comments	authorName, authorEmail, authorOrg, content, isPublic, staffResponse, respondedById	Consultation respondents; responding staff	0
grievance_records	filedBy, filedByUserId, anonymous, contactName, contactEmail, description, resolution, publicSummary, handledById, acknowledgementText	Grievants (including anonymous ones); handlers	0
reviewer_feedback	reviewer_name, reviewer_email, reviewer_org, feedback, user_agent, reviewer_locale, resolved_by	External reviewers	0
audit_log_entries	actorId, actorRole, organisationId, ipAddress, userAgent, previousState, newState, metadata	Every actor who takes a recorded action	240
workflow_transitions	actorId, actorRole, comment	Actors in workflow transitions	0
attestations	signerUserId, signerName, signerOrganisationId, signerRole, statement, ipHash, userAgent	Signatories of attestations	0
notifications	userId, title, message, escalatedTo	Notified users	512
error_log	message, stack, url, user_agent, user_id	Users who triggered a client error	79
governance_appointments	memberName, userId, role, appointedBy, createdById	Appointed governance body members	2
sanctions_screenings	subjectName, subjectIdentifiers, searchString, screenedById, resolutionNote, evidenceFilename	Screened natural persons (UBOs, officers); screening staff	0
vvb_accreditations	leadAuditors, references, assessorId, submittedById, applicationDetails	VVB staff — named Lead Auditors, technical experts, referees	0
vvb_accreditation_documents	originalFilename, uploadedById	Whoever a CV or certificate is about; uploader	0
vvb_performance_reviews	reviewedBy	Reviewing staff	0
edna_samples	contactEmail, requestedById, samplingLocation	Field contacts and requesters	0
vessel_intrusion_alerts	alertEmail, createdById	Alert recipients	0
methodology_interest	userId, organisationId, note	Interested users	0
project_wizard_drafts	userId, data (JSONB, free-form draft content)	Users drafting a project	2
esign_envelope	document_name, participants_json, initiated_by, signed_document_bytes, certificate_bytes	Signatories	0
documents, storage.objects	filename, originalFilename, and whatever the file itself contains	Anyone named in an uploaded document	21 stored objects across 3 buckets

4.3 Three columns deserve naming. audit_log_entries.ipAddress and audit_log_entries.userAgent hold identifiers of the actor on 12 of the 247 recorded actions (1 October 2026), none dated later than 28 March 2026, in a table whose class the Record Retention Schedule treats as long-lived; error_log.user_agent and error_log.user_id correlate a person to an application failure; and attestations.ipHash is a hashed rather than plain address, which is the correct pattern and which audit_log_entries does not follow. It is proposed that audit_log_entries.ipAddress be hashed on write, as attestations.ipHash already is. Hashing preserves the integrity purpose — proving two actions came from one origin — while removing the plain identifier. This is a privacy decision with an audit-integrity cost and belongs to the Governing Board on the Registry Oversight Committee's advice. (Consultation question 4.)

4.4 Free-text and file stores hold whatever was typed into them. contact_submissions.message, grievance_records.description, consultation_comments.content, project_wizard_drafts.data and every uploaded document may contain personal data about people who never dealt with the Programme. Minimisation SHALL be enforced at the point of collection by form design and by guidance, because it cannot be enforced afterwards by schema.

4.5 Special category data. The platform holds none. A scan of every column name in the public schema on 4 September 2026 for health, medical, biometric, genetic, racial, ethnic, religious, trade-union, sexual-orientation, political, criminal-conviction, gender and disability indicators returned zero columns. No table is designed to hold special category data, and none SHALL be added without a completed data protection impact assessment under Section 12.

4.6 edna_samples is not genetic data about people. Environmental DNA sampling captures genetic material shed by marine organisms into seawater. It is not human genetic data and is not special category data. The only personal data in that table is contactEmail, requestedById and, in samplingLocation, information which may identify where a named field worker was.

4.7 Two categories the corpus contemplates and the schema does not yet hold. MCC-ESS v2.0-draft cl. 16.6 and 16.7, and cl. 24.4, contemplate GBV/SEA/SH reports handled under survivor-centred confidentiality; the SDCF v1.0 cl. 0064 contemplates "[s]ensitive data (beneficiary identities, income levels, household information)". Neither has a store today, because no project has reached the stage that generates them. Both, when they arrive, will be special category or near-special-category data and SHALL NOT be collected into grievance_records or any general store without the assessment required by Section 12. Whether GBV/SEA/SH reports are held in the platform at all, or handled entirely off-platform under Safeguards & Rights Panel control, is not decided. Building the store is a decision to hold the data. (Consultation question 5.)

4.8 Sanctions screening. sanctions_screenings is designed to hold subjectName and subjectIdentifiers for natural persons screened against sanctions lists, and the KYC and Account Opening Procedure (draft) requires screening of beneficial owners and officers. Screening results are not criminal-conviction data, but a recorded match allegation about a named person is among the most consequential personal data the Programme will hold. It is classified RESTRICTED under MCC-820 cl. 4.1 (draft) and SHALL never be published.

4.9 Sources. Personal data is obtained from the data subject (registration, forms, submissions), from the organisation that nominates them (account representatives, Lead Auditors, referees), from the platform's own operation (audit, error and session records), and from public sanctions lists consulted at screening.

5. Purposes and lawful bases

5.1 Personal data SHALL be processed only for the purposes listed in the following table, each on the basis stated, and SHALL NOT be processed for a new purpose without a recorded compatibility assessment or a fresh basis.

#	Purpose	Data	Basis proposed
P1	Operating an account: authentication, session management, role assignment	users, auth.users, auth.sessions, userOrganisations	Performance of a contract (Registry Terms, Applicant Terms, VVB Terms)
P2	Customer due diligence and sanctions screening	organisations KYC columns, sanctions_screenings	Legal obligation where the Legal Entity's jurisdiction imposes one; otherwise legitimate interest in programme integrity — which applies turns on clause 3.1, and the entity has not yet been incorporated (Consultation question 2.)
P3	Running the registry: issuance, transfer, retirement, and the integrity of those records	audit_log_entries, workflow_transitions, attestations	Legitimate interest in the integrity and non-repudiation of a public environmental register
P4	Assessment, validation, verification and accreditation	vvb_accreditations, vvb_accreditation_documents, vvb_performance_reviews, project documents	Performance of a contract; legitimate interest in assurance quality
P5	Handling grievances and safeguards matters	grievance_records	Legitimate interest in remedy, and — where safeguards obligations bind — legal obligation; special handling per MCC-ESS §24 (draft)
P6	Consultation and public participation	consultation_comments, reviewer_feedback	Legitimate interest in open rule-making; consent for publication of a name (Section 6)
P7	Notifying and communicating with participants	notifications, contact_submissions	Performance of a contract, or legitimate interest for an unsolicited enquiry
P8	Marketing communications (newsletter)	newsletter_signups	Consent, freely given and withdrawable at any time
P9	Security, availability and fault diagnosis	audit_log_entries (ipAddress, userAgent), error_log, error-monitoring	Legitimate interest in securing a system that will hold a public register
P10	AI-assisted analysis within MCC-850	inputs drawn from the above	Legitimate interest; and MCC-850 v1.1 art. 39 requires applicant consent or Board discretion for anonymised model-improvement use
P11	Legal claims, audit and regulatory response	any of the above under legal hold (MCC-810 cl. 4.1, draft)	Legal obligation; establishment or defence of legal claims

5.2 Each legitimate-interest basis in the clause 5.1 table SHALL be supported by a recorded balancing assessment before this Policy takes effect; a basis asserted without one is not established. No balancing assessment exists for any purpose (confirmed by search of the adopted corpus, the consultation drafts and the platform on 4 September 2026).

5.3 Where consent is the basis (P6 publication, P8 newsletter, and the anonymised model-improvement use MCC-850 v1.1 art. 39 permits), consent SHALL be a positive act, SHALL be recorded with its date and scope, and SHALL be withdrawable by a route no harder than the route by which it was given. Withdrawal SHALL end the processing prospectively and SHALL NOT be used to revoke a publication that a different clause of Section 6 independently requires.

5.4 The Programme SHALL NOT sell personal data, SHALL NOT process it for automated decisions producing legal or similarly significant effects on a person, and SHALL NOT use it to train a third-party model outside the consent that clause 5.3 requires. MCC-ESS v2.0-draft cl. 3.5 and MCC-001 cl. 5.4 already prohibit an AI system being the deciding input to a safeguards, grievance or enforcement determination.

6. What is published, and where publication yields to privacy

6.1 The Programme's default is publication. The Transparency and Public Disclosure Policy v1.1 is an adopted instrument and commits the Programme to publishing a great deal. This Section reconciles that Policy with this one, clause by clause. Where the two conflict, the conflicts are named here rather than resolved silently.

6.2 Publication that does not yield to privacy. The following SHALL be published even though a natural person can be inferred from it, because the integrity of a public environmental register depends on it:

6.2.1 the identity of the organisation holding, transferring or retiring a unit — the Transparency Policy §2.2 already restricts this to organisations, publishing "[c]urrent owner (organization name; NOT individual names for privacy)", and the Registry Terms art. 8.1 states the same restriction for transfer history;

6.2.2 the name of a natural person who is the Account Holder acting in a business capacity, or who has consented — this is the rule MCC-800 v2.0-draft cl. 18.4 proposes, and this Policy adopts the same line;

6.2.3 the names of members of the governance bodies and the record of their decisions and votes — the Transparency Policy §2.5 publishes "[m]eeting date and attendees (Board member names)", dissenting opinions and vote splits, and the Registry Terms art. 8.2 confirms that staff details are withheld "except board members, who publicly disclosed". Accountability for a governance decision is not a privacy interest a decision-maker may assert;

6.2.4 the name of the accredited VVB and its accreditation status (Transparency Policy §2.1A), and the identity of the applicant on a validation or verification report (Registry Terms art. 8.1).

6.3 Publication that yields to privacy. The following SHALL NOT be published, in the terms the Transparency Policy art. 3(1) already uses — individual names "unless public figure or community leader consenting"; "National ID numbers, passport numbers, family relationships"; "[p]ersonal contact info (phone, home address)"; and email addresses, staff emails "generally not public":

6.3.1 personal data of community members and beneficiaries, which Applicant Terms art. 8.3 withholds — "[p]ersonal names and contact info of community members", "[p]ersonal identification numbers", "[f]amily relationships or sensitive biographical data" — subject to the same consent exception for community leadership;

6.3.2 grievance and FPIC records and the identity of any grievant, survivor or human-rights defender, per MCC-ESS v2.0-draft cl. 24.1, 24.3 and 24.4; grievance_records.anonymous SHALL be honoured and an anonymous grievant's identity SHALL NOT be sought;

6.3.3 the personally identifiable information of a non-permanence risk assessor, which the Buffer Pool Management Policy v1.0 cl. 0179 requires to be "redacted if requested" — a request-based redaction this Policy treats as a floor, not a ceiling;

6.3.4 conflict-of-interest check details, which the Foundational Decisions v1.0 record as "privacy-sensitive";

6.3.5 sensitive beneficiary data — "beneficiary identities, income levels, household information" (SDCF v1.0 cl. 0064) — which SHALL be published only in aggregate, consistent with the umbrella methodologies' requirement (cl. 11.11.1, 12.11.1, 13.11.1) that monitoring data be "aggregated to protect operator privacy", "individual collector privacy" and "individual community privacy" respectively;

6.3.6 sanctions screening material and due-diligence files (clause 4.8);

6.3.7 anything within the withholding grounds of MCC-700 v3.0 cl. 14.3, and — on entry into force — the lawful redaction rules of MCC-100 v3.0-draft cl. 20.7.

6.4 Publication that requires consent, and what happens when consent is refused. The Transparency Policy publishes three things "with consent". Consent that cannot be refused is not consent, so this Policy states the consequence of refusal in each case:

6.4.1 the consultation attendee list — Transparency Policy §2.10 publishes "[a]ttendee list (names, organizations; with attendee consent)". Where an attendee refuses, their name SHALL be omitted and the attendance SHALL be published in aggregate ("n attendees, of whom m consented to be named") so that the meeting's scale remains verifiable. Refusal SHALL NOT exclude a person from attending;

6.4.2 FPIC documentation — §2.10 publishes it "(for indigenous communities; with community consent)". Where community consent is refused or qualified, a meaningful public summary SHALL be published instead, per MCC-ESS v2.0-draft cl. 24.2, so that the fact and outcome of the FPIC process remain public even where its documents are not;

6.4.3 VVB calibration audit findings — §2.6 publishes them "(per VVB; published with VVB consent)". A VVB is not a data subject, and this is a commercial consent, not a privacy one. This Policy SHALL NOT be cited as authority for a VVB withholding its calibration findings.

6.5 Written consultation comments are published anonymised. Transparency Policy §2.10 publishes "[c]omments received during 30-day written period (anonymized)". The platform's consultation_comments table nonetheless holds authorName, authorEmail and authorOrg alongside an isPublic flag. Those columns SHALL be treated as non-public by default, and isPublic SHALL govern only the comment content, not the author identity, unless the author has consented to be named under clause 5.3.

6.6 Three conflicts inside the adopted Transparency Policy that this Policy cannot resolve alone. Each is a conflict between adopted text and adopted text; resolving it is an amendment, not a drafting choice:

6.6.1 §2.1F publishes, for every registered project, "Contact (project lead name, email, phone)". Article 3(1) of the same Policy withholds "[p]ersonal contact info (phone, home address)" and treats email addresses as shared only "if permitted". A named individual's telephone number is published by §2.1F and withheld by art. 3(1). Pending resolution, this Policy applies art. 3(1): the project lead's name and a role-based organisational contact address SHALL be published; a personal telephone number SHALL NOT. Whether §2.1F is amended to a role-based contact, or art. 3(1) is amended to carve out the project lead, is not decided; the Governing Board must choose one. (Consultation question 6.)

6.6.2 §2.5 commits to publishing "Technical Committee monthly meeting summaries". No instrument constitutes a Technical Committee: MCC-700 v4.0-draft cl. 4.1 would provide that the architecture comprises "exactly the following seven governance bodies … no body other than those seven SHALL exercise governance authority", and the seven are the Independent Governing Board, Standards Committee, VVB Oversight Committee, Registry Oversight Committee, Safeguards & Rights Panel, Independent Appeals Panel and Programme Secretariat. "Technical Committee" appears nowhere in MCC-700 v3.1, which the document register records as in force (FD-2026-08-24 item D11). This Policy therefore assigns no privacy duty to a Technical Committee and records the gap. The same caution applies to the "Methodology Working Group" and "Safeguards Review Panel" named in §2.5.

6.6.3 §2.8 publishes per-VVB "[a]pplicant satisfaction (average star rating if surveyed)". Where few applicants exist — today, none — an average of a very small number of ratings is attributable to identifiable individuals. A satisfaction metric SHALL NOT be published where fewer than five independent responses underlie it. The Board may set a different minimum; five is proposed, not decided. (Consultation question 7.)

6.7 A field SHALL NOT be published unless it is classified as publishable in the registry data dictionary. MCC-800 v2.0-draft cl. 17.8 would require that "every public field SHALL be classified in the registry data dictionary as mandatory-public, optional-public (lawful-basis gated) or non-public". No such data dictionary exists. Its absence was confirmed by search on 4 September 2026. Until it exists, publication decisions rest on this Section read with Transparency Policy art. 2 and 3, field by field.

6.8 Classification SHALL NOT be used to withhold information that the transparency instruments require to be public (the principle MCC-820 cl. 4.4, draft, states). Privacy is a reason to redact a name; it is never a reason to suppress a quantity, a decision, a deduction or a serial.

7. Data subject rights: how a request is made and how it is answered

7.1 A data subject MAY exercise the rights of access, rectification, erasure, restriction of processing, objection to processing, and portability, to the extent the applicable law confers them. MCC-800 v1.0 art. 90 already confers access, rectification and erasure expressly, "subject to the overriding retention requirements for registry integrity".

7.2 How a request is made. A request SHALL be made by email to info@marineconservationcredits.com, or through the contact form on the public website, or in writing to the Legal Entity's registered office once clause 3.1 is resolved. A request SHALL NOT be refused for using the wrong route, the wrong words, or for not citing this Policy; any communication that a reasonable reader would understand as such a request SHALL be treated as one.

7.3 Identity. The Programme SHALL verify the requester's identity proportionately before disclosing or altering personal data, SHALL NOT demand more identifying information than the verification requires, and SHALL NOT use information supplied for verification for any other purpose.

7.4 Time limit. A request SHALL be acknowledged within five business days and answered within one calendar month of receipt. The period MAY be extended once, by up to two further months, where the request is complex or where several requests have been made by the same person; the extension and its reason SHALL be notified to the requester within the first month. The Programme SHALL NOT charge a fee for a first request.

7.5 Answering an access request. The response SHALL state the purposes, the categories of personal data, the recipients, the retention period or the criteria fixing it, the rights available and the route to complain to a supervisory authority, and SHALL enclose a copy of the personal data. The copy SHALL be assembled from the stores listed in clause 4.2 and SHALL NOT omit the audit, error and notification records merely because they are operational.

7.6 Answering an erasure request. Where a record must be retained, 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 the retention expiry with the data subject informed of the basis — the mechanic MCC-810 cl. 4.3 (draft) states and MCC-800 v2.0-draft cl. 18.3 adopts. A refusal SHALL always give reasons and SHALL always state when the record will expire.

7.7 The registry is not a general exception. A response SHALL NOT refuse erasure by pointing at "registry integrity" without identifying the specific record, its class, and why de-identification would defeat its purpose. MCC-810 cl. 4.4 (draft) requires that the permanent classes R1, R6 and R14 "SHALL be designed to exclude personal data or to hold it only in severable form … so that permanence never forces permanent personal-data retention". Where a permanent record does contain inseverable personal data, that is a design defect to be fixed, not a right to be denied.

7.8 A refusal, in whole or in part, SHALL be recorded with its reasons, and the requester SHALL be told of their right to complain to a supervisory authority and of any internal review route. Whether a refusal is reviewable internally, and by whom, is not decided. The Independent Appeals Panel (MCC-700 v4.0-draft cl. 4.10), to which no member has been appointed, hears appeals against programme decisions; whether a privacy refusal is such a decision is not settled anywhere. (Consultation question 8.)

7.9 The Programme SHALL keep a register of rights requests — date received, category, outcome, date answered — and SHALL report the counts in the transparency reporting cycle without identifying requesters.

7.10 Every data subject retains the right to complain to a supervisory authority. Which authority is competent cannot be stated until clause 3.1 is resolved, and this Policy SHALL NOT name one before then.

8. Retention

8.1 Retention, disposition and legal hold are governed exclusively by the MCC Record Retention Schedule. This Policy states no retention period. The Record Retention Schedule is a consultation draft (v1.0-draft, 3 September 2026) and is not in force. The no-destruction rule the rewritten suite would apply until it takes effect is also in consultation drafts and is not in force; clause 8.3 states the periods that are.

8.2 The classes bearing most directly on personal data are R1 (registry unit and transaction records — permanent, "personal data excluded by design"), R5 (project records including grievance and consultation records — ten years after the end-of-life trigger, "grievance records containing personal data minimised at resolution + 10 years") and R6 (governance records — permanent, "personal data in complaint/appeal files minimised 10 years after closure"). The Schedule, not this Policy, is the authority for each.

8.3 Until the Record Retention Schedule is in force, the retention periods in force are those of MCC-800 v1.0 Section 14 — credit unit records permanent; audit trail records minimum 20 years; account records 10 years post-closure; workflow records 10 years post-completion; notification records 5 years; API access logs 2 years — together with the periods in the Legal and Regulatory Positioning Statement v1.1 art. 5.3. These two in-force sources do not agree with each other, and the Retention Schedule exists to resolve exactly that. This Policy records the divergence and defers.

8.4 MCC-800 v1.0 art. 89 requires the Registry Manager to "conduct an annual data retention review to confirm compliance with retention periods and to identify any data eligible for deletion under applicable data protection regulations". No retention review is recorded in the programme record (search of 4 September 2026). The Standard took effect on 1 April 2026 (art. 107); the first annual review falls due 1 April 2027.

8.5 Indefinite retention without a documented lawful basis is prohibited (MCC-810 cl. 1.4, draft).

9. Where the data actually sits, and international transfers

9.1 The primary data store is a Supabase-hosted PostgreSQL 17 project named "MCC Platform" (project ref ifflkkpowmzjoochwavf), created 25 March 2026, in region eu-north-1 — Stockholm, Sweden. Verified against the project record on 4 September 2026. Every table in the clause 4.2 inventory, the auth schema and the three storage buckets sit there. The Programme's personal data is therefore held in the EU/EEA.

9.2 This Policy SHALL state the actual region and SHALL be amended whenever it changes. A statement that data is held "within the European Economic Area" without naming where is not sufficient (Section 15).

9.3 Personal data leaves that region where an external service is called. The following external endpoints are called from the platform's server code and MAY receive personal data:

Service	Endpoint	Personal data it can receive	Status
Supabase (database, authentication, object storage)	project ifflkkpowmzjoochwavf, eu-north-1	all of clause 4.2	EU/EEA region; no contracting entity, processor terms or transfer mechanism is recorded in the programme record (clauses 9.5 and 10.1)
Vercel (application hosting)	marineconservationcredits.com, staging.marineconservationcredits.com	request data, IP addresses, anything in transit	server functions pinned to region arn1, Stockholm, in vercel.json (MCC-DRBC v1.0-draft cl. 3.2)
Resend (email transport)	api.resend.com	recipient email address, message content	the notification queue records 92 notifications as SENT and 428 as EXPIRED (1 October 2026)
Sentry (error monitoring)	configured by NEXT_PUBLIC_SENTRY_DSN	error context; sendDefaultPii is set to false in sentry.client.config.ts	active where the DSN is set
Anthropic (AI analysis under MCC-850)	api.anthropic.com	whatever is placed in a prompt	active where the API key is set
NatureMetrics (eDNA)	api.naturemetrics.com	edna_samples.contactEmail, sampling location	no samples recorded
OFAC sanctions search	sanctionssearch.ofac.treas.gov	the name being screened	no screening recorded

9.4 The environmental and Earth-observation endpoints the platform also calls — GBIF, OBIS, Copernicus, Planet, Global Mangrove Watch, Allen Coral Atlas, UNEP-WCMC, Spire — receive coordinates and imagery requests, not personal data, and are outside this Section save where a request itself identifies a person.

9.5 No transfer mechanism is recorded for any of the services in clause 9.3. A search of the adopted corpus, the consultation drafts and the repository on 4 September 2026 found no standard contractual clauses, adequacy reliance or other transfer instrument. MCC-850 v2.0-draft cl. 15.5 would require that transfers "SHALL occur only under a recorded transfer mechanism valid in the relevant jurisdictions"; that requirement is not yet in force and is not yet met.

9.6 A transfer of personal data outside the EU/EEA SHALL NOT be made under this Policy until clause 9.5 is discharged and clause 3.1 fixes whose transfer it is.

10. Processors and sub-processors

10.1 No processor register exists. A search of the review corpus, the adopted corpus, the consultation drafts and the platform repository on 4 September 2026 found no processor register, no record of processing activities and no executed data processing agreement. The table at clause 9.3 was reconstructed from the code, not from a register, and is therefore a starting point for one rather than the register itself.

10.2 The Programme SHALL establish and maintain a register of processors and sub-processors, recording for each: the service, the personal data it processes, the purpose, the location of processing, the transfer mechanism, the contract reference, and the date of the last risk assessment. Clause 9.3 SHALL be superseded by that register on its establishment.

10.3 A processor SHALL be engaged only under written terms binding it to process only on documented instructions, to security obligations no weaker than the Information Security Standard, to breach notification without undue delay, to sub-processor transparency and flow-down, and to return or destruction of data at exit — the terms MCC-820 cl. 12.2 (draft) requires of supplier contracts.

10.4 A processor SHALL be risk-assessed before engagement and periodically thereafter (MCC-820 cl. 12.1, draft). No such assessment is recorded for any service in clause 9.3.

10.5 A conflict with an in-force instrument must be recorded here. MCC-850 v1.1 art. 39, which is in force, provides that AI-processed data is subject to "[n]o third-party data sharing without explicit Board approval" and that "[e]xternal integrations … require Board authorization per integration". The platform integrates with at least seven external services (clause 9.3), and no decision of the Governing Board (constituted 26 August 2026 by GB-2026-001, which is recorded in the decision register as attested by the founder, with no executed copy filed) authorising any of them is recorded. Art. 40 further requires a "[d]ata residency policy established by PA and approved by Board"; none exists. These are unmet obligations of an in-force document, not defects of this draft, and they SHALL be reported to the Governing Board, which was constituted on 26 August 2026.

10.6 Recipients other than processors are: independent VVBs, in the course of validation and verification; host-country authorities, where an authorisation instrument requires it; auditors and the independent assurance function; and regulatory or judicial authorities where compelled. Each SHALL receive the minimum the purpose requires.

11. Personal data breaches

11.1 A personal data breach is any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data — whether or not the data was exfiltrated, and whether or not it was encrypted.

11.2 Internal route. Any person who becomes aware of a suspected personal data breach SHALL report it immediately to the security owner designated under MCC-820 cl. 3.1 (draft) and to the privacy owner designated under MCC-800 v2.0-draft cl. 18.1. Neither role has been filled. It is proposed that, until a Programme Secretariat exists, the security owner is the Programme Administrator, disclosed as such; no proposal is made for the privacy owner. (Consultation question 9.) Until a privacy owner is designated, reports go to the security owner, and the escalation path in clause 11.4 cannot be operated as written.

11.3 The breach SHALL be triaged immediately (MCC-820 cl. 11.2, draft), assessed for risk to the rights and freedoms of the data subjects, and recorded — the assessment SHALL be recorded even where no notification is required (MCC-820 cl. 11.4, draft).

11.4 Deadline to the supervisory authority: 72 hours. A notifiable personal data breach SHALL be notified to the competent supervisory authority within 72 hours of the Programme becoming aware of it. This deadline is not new: the Legal and Regulatory Positioning Statement v1.1 art. 5.2, adopted by FD-2026-08-24, already places on the data protection officer the duty to "[i]nvestigate data breaches (notify EU authorities within 72 hours if material)". Where the 72 hours cannot be met, the notification SHALL be made without further delay with the reasons for the delay.

11.5 Deadline to data subjects: without undue delay. Where a breach is likely to result in a high risk to a data subject, that subject SHALL be notified without undue delay, in plain language, stating what happened, what data was affected, the likely consequences, what the Programme has done, and who to contact.

11.6 Where the breach affects an Account Holder's account, units or data, the participant-notification duty of MCC-820 cl. 11.3 (draft) applies in addition, and is not satisfied by a supervisory-authority notification.

11.7 A breach affecting registry data integrity SHALL additionally trigger the reconciliation actions of the Registry Operations Standard, and a post-incident review SHALL be completed within ten business days of closure with root cause, impact and remediation recorded (MCC-820 cl. 11.5, draft; MCC-800 v1.0 art. 94 imposes the equivalent ten-business-day review for outages today).

11.8 Material breaches SHALL be reported to the Registry Oversight Committee and to the Governing Board. The Registry Oversight Committee is not constituted. Until it is, the report due to it SHALL be made to the founder and recorded, and the record SHALL be tabled for ratification when it is constituted.

11.9 A breach register SHALL be maintained recording every breach and near-miss, its assessment, the notification decision and its reasons, and the remediation. Its aggregate counts SHALL be published in the transparency reporting cycle.

11.10 No breach has been recorded, and no incident-response plan exists. Neither the documented incident-response plan that MCC-820 cl. 11.1 (draft) would require nor its annual exercise exists; both were confirmed absent on 4 September 2026.

12. Data protection impact assessment

12.1 A data protection impact assessment (DPIA) SHALL be completed before any processing likely to result in a high risk to data subjects begins, and SHALL be reviewed on material change.

12.2 A DPIA for the registry is a condition of issuance. MCC-800 v2.0-draft cl. 18.5 provides: "A data protection impact assessment SHALL be completed for the registry before issuance is enabled, and reviewed on material change." That clause is in a consultation draft and is not yet in force.

12.3 No DPIA has been completed, for the registry or for anything else. None existed on 3 September 2026 (Evidence Register ER-2026-001 §B5). DPIA-2026-001, a first assessment of the registry and the AI Analysis Layer, has since been drafted: it is a draft assessment in the proposal set, excluded from this consultation because it proposes no rule (FD-2026-09-04 item 2), and it has not been reviewed by a qualified data protection adviser, which FD-2026-09-04 item 5 resolved must happen before any credit is issued. FD-2026-09-04 is recorded in the decision register as attested by the founder; no executed copy has been filed.

12.4 A DPIA SHALL be completed for, at minimum: the registry (cl. 12.2); each AI system in scope of MCC-850, which MCC-850 v2.0-draft cl. 15.3 would require "before any in-scope system is deployed or materially changed"; sanctions screening; and any store created to hold grievance, GBV/SEA/SH, FPIC or beneficiary data (clause 4.7).

12.5 The DPIA SHALL be recorded, retained, and available to the supervisory authority and to the Registry Oversight Committee; its non-sensitive conclusions SHOULD be published.

12.6 On the premise that this document was commissioned to test. It has been said in the programme record that MCC-800 clause 19.4 makes a Privacy Policy, together with a disaster recovery and business continuity plan, a gate on issuance. That is not what clause 19.4 says. Verified on 4 September 2026: in MCC-800 v2.0-draft, cl. 19.4 is about security testing — "independent penetration testing at least annually and before issuance is first enabled"; the privacy gate on issuance is cl. 18.5 (the DPIA); the business continuity and disaster recovery plan is cl. 20.2; and the Privacy Policy itself is required by cl. 18.1, which is not expressed as a gate at all. In the in-force MCC-800 v1.0 there is no clause 19.4 (Section 19 is Transitional Provisions, art. 107–110); the Privacy Policy is required by art. 90 and the Disaster Recovery Plan by art. 91, and neither is a condition of issuance. The correct statement is that three separate pre-issuance conditions exist — cl. 18.5 (DPIA), cl. 19.4 (penetration test) and, on the security side, MCC-820 cl. 9.1 — and none of them has been met, while the Privacy Policy and the DR/BC plan are freestanding obligations that are also unmet.

13. Children's data

13.1 The Programme has no reason to hold personal data about children and SHALL NOT knowingly collect any. Every relationship the Programme has is with a professional acting for an organisation: an account representative, a project developer, a VVB auditor, a governance body member, a consultation respondent, a grievant. None of these is a role a child occupies.

13.2 No platform service is directed at children, and no store in clause 4.2 holds a date of birth or age. Verified: no column in the public schema records age or date of birth.

13.3 Where a child's personal data nevertheless reaches the Programme — most plausibly inside a free-text field or an uploaded safeguards or consultation document (clause 4.4) — it SHALL be minimised or removed at the earliest point consistent with the record's purpose, and SHALL NOT be published in any circumstance, including where clause 6.2 would otherwise require publication of the surrounding record.

13.4 An age-verification mechanism SHALL NOT be introduced, because introducing one would require collecting the age data this Section exists to avoid.

14. Security

14.1 Security controls are stated in the Information Security Standard and not here. This Policy states no encryption algorithm, key length, authentication technology or security parameter; each is reserved to that Standard (MCC-820 cl. 1.1, draft), which classifies personal data as CONFIDENTIAL and sanctions-investigation material and data whose disclosure could endanger persons as RESTRICTED (cl. 4.1).

14.2 The Information Security Standard is a consultation draft and is not in force. Until it takes effect, the in-force security requirements applicable to personal data are those of MCC-800 v1.0 (including art. 88: archived data "stored in encrypted, geographically redundant storage") and MCC-850 v1.1 art. 41–42.

14.3 The Programme SHALL NOT represent that it performs "regular security assessments" until MCC-820 cl. 9.1 or 9.2 has been satisfied at least once. No independent penetration test and no independent security assessment has been performed (Evidence Register ER-2026-001 §B5; re-confirmed 4 September 2026).

15. The published /privacy notice, and how it diverges

15.1 A privacy notice is served at /privacy on the public website, headed "Interim notice — corrected 4 September 2026". It is not an instrument: it has no version, no effective date, no owner, no approval, and it is not in src/lib/documents/manifest.ts. It is nonetheless the only privacy statement any data subject has ever been shown, and this Policy SHALL NOT be read as claiming that no privacy notice exists.

15.2 On entry into force, this Policy SHALL replace that notice, and the notice SHALL be rewritten to be a plain-language summary of this Policy with no statement this Policy does not support.

15.3 The following statements in the served notice could not be verified on 4 September 2026 and SHALL be corrected or removed (the first six were corrected or removed on 4 September 2026, PR #237; the seventh was accurate; the omissions in the last row remain):

The notice said, until 4 September 2026	What was verified
"Marine Conservation Credits ('MCC', 'we', 'us', or 'our') is committed to…" — an unnamed "we"	No controller exists to be named (Section 3). The notice should say so.
"We may also use analytics cookies to understand how visitors interact with our site."	No analytics library is present. The only third-party client instrumentation in apps/web/package.json is @sentry/nextjs, configured with sendDefaultPii: false. No analytics or advertising cookie was found. The claim over-declares.
"We may share information with … affiliated entities within our organization."	There is no organisation and there are no affiliates.
"Where data is transferred outside the EEA, we ensure appropriate safeguards are in place, including Standard Contractual Clauses (SCCs)."	No SCC, adequacy reliance or other transfer mechanism is recorded for any service (clause 9.5).
"All third-party service providers are contractually obligated to protect your data in accordance with this policy."	No processor register and no data processing agreement is recorded (clause 10.1).
"These measures include encryption, access controls, and regular security assessments."	No security assessment has been performed (clause 14.3).
"Our platform infrastructure is hosted within the European Economic Area (EEA)."	Correct as far as it goes, and now stated precisely: Supabase eu-north-1, Stockholm (clause 9.1). Vercel's server functions are pinned to region arn1, Stockholm (clause 9.3).
Silent on: retention periods, breach notification, the response deadline for a rights request, the supervisory authority, the DPO, children's data	Sections 7, 8, 11 and 13 supply each.

15.4 The served notice's contact route — info@marineconservationcredits.com — is verified as the address published on the site, and is adopted as the rights-request route in clause 7.2 until a dedicated privacy address exists. A dedicated address such as privacy@, which would separate rights requests from general enquiries in contact_submissions, is proposed and not decided. (Consultation question 10.)

16. Maintenance, review and amendment

16.1 This Policy SHALL be reviewed at least annually, and additionally on: incorporation of the Legal Entity; any change of applicable law; any change of hosting region or of a processor; entry into force of the Record Retention Schedule or the Information Security Standard; completion of the first DPIA; and any personal data breach.

16.2 The document owner SHALL verify at each review that the clause 4.2 inventory still matches the database schema, and SHALL amend it where it does not. An inventory that has drifted from the schema is worse than none, because it will be relied on.

16.3 This Policy MAY be amended through the Tier 5 amendment route of the Document Hierarchy and Precedence Register. During the transitional period, amendment is by Founder Decision recorded and tabled for ratification under the governance instrument in force.

16.4 A material amendment SHALL be notified to registered users before it takes effect, and the previous version SHALL remain published with its effective dates.

16.5 This Policy SHALL enter into force upon approval by the authority the Charter fixes for Tier 5 instruments. It does not enter into force by being published, and until it does, MCC-800 v1.0 art. 90 continues to point at a document that does not exist.

---

Annex — Open items

Facts not yet in the programme record, or in it only in part

#	Item	Why it blocks
F1	The controller's legal name, jurisdiction, company number and registered office (cl. 3.1)	Without it there is no controller, no competent supervisory authority (cl. 7.10), no party to a processor contract (cl. 10.3), and no applicable law (cl. 2.2)
F2	Appointment of a data protection officer, or a recorded determination that none is required (cl. 3.5)	Legal and Regulatory Positioning v1.1 art. 5.2 is adopted and unmet
F3	Designation of the privacy owner and the security owner (cl. 11.2)	The breach escalation route in Section 11 cannot be operated without them
F4	Vercel deployment region (cl. 9.3)	Answered for server functions: pinned to arn1, Stockholm (cl. 9.3)
F5	Whether P2 (due diligence and sanctions screening) rests on legal obligation or legitimate interest (cl. 5.1)	Turns entirely on F1
F6	Executed processor terms and transfer mechanisms for the services at cl. 9.3	Clauses 9.5, 9.6, 10.1 and 10.4 are unmet without them

Questions reserved to the Governing Board

#	Question	What is proposed
B1	GDPR as the committed baseline regardless of incorporation, or whichever regime the entity's jurisdiction imposes (cl. 2.2)	Nothing proposed
B2	Whether audit_log_entries.ipAddress is hashed on write, as attestations.ipHash already is (cl. 4.3)	Hashing, with the integrity cost stated
B3	Whether GBV/SEA/SH reports are held on the platform at all (cl. 4.7)	Nothing proposed; building the store is a decision to hold the data
B4	Transparency Policy §2.1F (publish project lead name, email, phone) against art. 3(1) (withhold personal contact info) (cl. 6.6.1)	Interim: apply art. 3(1). One of the two clauses must be amended
B5	The Technical Committee, Methodology Working Group and Safeguards Review Panel named in Transparency Policy §2.5 but constituted by no instrument (cl. 6.6.2)	No duty assigned to them; the gap recorded
B6	Minimum response count before a per-VVB satisfaction average is published (cl. 6.6.3)	Five
B7	Whether a refusal of a data subject request is internally reviewable, and by whom (cl. 7.8)	Nothing proposed
B8	A dedicated privacy@ address, separating rights requests from general enquiries (cl. 15.4)	Proposed, not decided

Evidence outstanding

Registry data dictionary (cl. 6.7) · legitimate-interest balancing assessments (cl. 5.2) · processor and sub-processor register (cl. 10.1) · processor risk assessments (cl. 10.4) · transfer mechanisms (cl. 9.5) · incident-response plan and its annual exercise (cl. 11.10) · the registry DPIA required before issuance (cl. 12.3) · the annual data retention review due 1 April 2027 (cl. 8.4) · independent penetration test and security assessment (cl. 14.3) · Board authorisation of external integrations and the data residency policy required by MCC-850 v1.1 art. 39–40, both in force and both unmet (cl. 10.5).

---

Prepared 4 September 2026 for public consultation. Evidence checked on 4 September 2026: the review corpus at ~/mcc-review/txt (34 in-force texts, searched for "personal data", "privacy", "GDPR", "data protection", "DPIA", "retention", "consent", "personally identifiable" and "data subject") — in particular MCC-800 v1.0 art. 88–94 and 107, MCC-850 v1.1 art. 39–42, MCC-700 v3.0 cl. 14.1–14.5, Buffer Pool Management Policy v1.0 cl. 0179, SDCF v1.0 cl. 0064, ESS Policy v1.0 cl. 0018 and 0131, the Ten Operational Umbrella Methodologies cl. 11.11.1, 12.11.1 and 13.11.1, Foundational Decisions v1.0, and the Applicant, Registry and VVB Terms; the served adopted corpus at content/adopted/ and the manifest at src/lib/documents/manifest.ts — in particular Transparency and Public Disclosure Policy v1.1 art. 2.1, 2.2, 2.5, 2.6, 2.8, 2.10 and art. 3, Legal and Regulatory Positioning Statement v1.1 art. 1.2 and art. 5.1–5.3, and the Programme Factsheet; the consultation drafts at content/proposals/ — MCC-800 v2.0-draft §17–20, MCC-810 Record Retention Schedule (draft, not in force), MCC-820 Information Security Standard (draft, not in force), MCC-850 v2.0-draft §15, MCC-100 v3.0-draft §20, MCC-ESS v2.0-draft §24, MCC-700 v4.0-draft §2 and §4, the KYC and Account Opening Procedure, the Definitions Register amendment cl. 3.2.2, and the Fee Schedule draft for document-control house style; the platform database (Supabase project ifflkkpowmzjoochwavf, region eu-north-1, PostgreSQL 17, created 25 March 2026) — every column of the public schema read from information_schema.columns, row counts taken for each store in clause 4.2, auth and storage counted, and a special-category column scan run which returned zero results; and the platform repository — apps/web/src/app/privacy/page.tsx, apps/web/package.json, sentry.client.config.ts, and the external endpoints called from src/lib and src/app/api. Nothing in this draft is approved, and nothing in it is in force.*