MCC-ISS — Information Security Standard

Document control

Field	Value
Document code	MCC-820, proposed as its register code in place of the working code MCC-ISS used in this draft (FD-2026-10-01 Schedule 1, Q22) (Consultation question 1.)
Title	Information Security Standard
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; canonical security control source cited by the Tier 2–3 documents, which state no security parameters of their own)
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 … Information Security Standard. Policies should reference the canonical controls rather than hard-code conflicting technology requirements") and finding 800-10. This is a new document: no predecessor exists; security clauses were previously duplicated and divergent across the suite (for example "TLS 1.3 or later", MCC-800 v1.x Art. 22, against "TLS 1.2+", Buffer Policy v1.0 cl. 0169).
Supersedes	None (new document). On entry into force it supersedes every local security parameter 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 Standard states control objectives and requirements as current good practice, by reference to authoritative published guidance, deliberately avoiding hard-coded protocol versions, algorithms and numeric parameters that age into defects (the TLS 1.2-vs-1.3 divergence the audit found is exactly that failure mode). Concrete technology selections satisfying these requirements are to be recorded in the Registry Architecture Specification (MCC-800 v2.0-draft cl. 1.6), which does not yet exist, and in equivalent per-system architecture records, which MUST be kept current against this Standard. Nothing here asserts that any control is implemented or tested; implementation evidence belongs in the Evidence Register (audit acceptance test QA-13).

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-820, in place of the working code MCC-ISS, 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 3.1 — security owner. Proposed: the Programme Administrator is the security owner, disclosed as such, until a Programme Secretariat exists. Basis: FD-2026-10-01 Schedule 1 (Q13); FDP-2026-001 Q13. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether this transitional designation is acceptable.

1. Purpose, scope and application

1.1 This Standard is the single canonical source of information security requirements for the MCC Programme, reserved to it by the deferrals of MCC-800 Section 19, MCC-850 Section 16 and their peers; no other Programme document SHALL state a security control parameter. A conflicting statement in a document of a tier lower than this Standard is void to the extent of the conflict once this Standard is in force; a conflict with a higher-tier document is resolved under MCC-001 Section 2, and this Standard is read down to conform.

NOTE. A "no local security parameter" reservation of the kind MCC-001 clause 10.8 makes for the Record Retention Schedule is proposed for a revision of MCC-001 after v3.0, so that this Standard has the same Tier 1 anchor; the MCC-001 v3.0 draft put to consultation with this Standard does not carry it.

1.2 This Standard applies to every information system processing Programme information — the registry platform above all (MCC-800 Section 19), the public website and surfaces, AI systems (MCC-850 as reissued), corporate systems holding Programme records — and to every person and supplier operating or accessing them.

1.3 Requirements SHALL be applied proportionately to system criticality and information classification (Section 4); the registry platform SHALL always be treated at the highest criticality.

1.4 Where this Standard requires "current good practice", the operating function SHALL implement the current published recommendations of authoritative bodies (national cyber-security authorities, recognised standards organisations and, for web applications, the current OWASP guidance), record in the architecture specification which recommendation is followed, and review the selection at least annually and on material change of the guidance.

2. Definitions and interpretation

2.1 Terms with initial capitals bear the meanings of the MCC Definitions Register; "architecture specification" means the controlled Tier 5 record of concrete technology selections for a system (for the registry, the Registry Architecture Specification of MCC-800 clause 1.6); "high-impact action" means any action listed in MCC-800 clause 4.2, any privileged administrative action, and any action so designated in an architecture specification.

2.2 The normative verb conventions of MCC-001 clause 3.1 apply; each numbered clause states one testable requirement; NOTE text is non-normative.

3. Governance and accountability

3.1 A named security owner SHALL be accountable for this Standard's implementation across the Programme, with direct reporting access to the Registry Oversight Committee for registry security and to the Governing Board for Programme-wide risk. No security owner has been designated. It is proposed that, until a Programme Secretariat exists, the security owner is the Programme Administrator, disclosed as such. (Consultation question 2.)

3.2 Registry security oversight is vested in the Registry Oversight Committee (MCC-700 clause 4.8); security decisions reserved to bodies are taken through MCC-700 Annex A, and this Standard designates no decision owner.

3.3 A documented information-security risk assessment SHALL be maintained per system, reviewed at least annually and on material change, with treatment decisions recorded.

3.4 Security controls SHALL be included in the annual independent registry audit (MCC-700 clause 4.8.3), and a summary of each independent security assessment SHALL be published.

3.5 Exceptions to this Standard SHALL be granted only in writing, with a compensating-control analysis, an expiry date not exceeding twelve months, and approval recorded through the clause 3.2 routes; expired exceptions lapse automatically.

4. Information classification and handling

4.1 All Programme information SHALL be classified into exactly one of: PUBLIC (intended for publication — the registry public surfaces, adopted documents); INTERNAL (operational information whose disclosure causes limited harm); CONFIDENTIAL (participant business information, due-diligence files, unpublished decisions, personal data); RESTRICTED (security credentials and keys, sanctions-investigation material, incident forensics, data whose disclosure could endanger persons or reveal sensitive locations, per MCC-100 clause 20.7).

4.2 Every data store, export and interface SHALL carry a recorded classification, and the registry data dictionary SHALL classify every registry field (MCC-800 clause 17.8).

4.3 Handling rules per classification — storage, transmission, sharing, labelling and disposal — SHALL be documented and enforced; RESTRICTED information SHALL never leave controlled systems except under a recorded, approved transfer.

4.4 Classification SHALL NOT be used to withhold information that MCC-100 Section 20 or this Standard's transparency provisions require to be public.

5. Access control and identity assurance

5.1 Access SHALL follow least privilege and need-to-know: every permission SHALL trace to a role defined in the applicable architecture specification, and standing permissions SHALL be reviewed at least quarterly for privileged roles and at least annually for all roles, with review evidence retained.

5.2 Every identity SHALL be individual and attributable to a named natural person or a registered service identity; shared and generic accounts are prohibited.

5.3 All write access SHALL require multi-factor authentication; authentication for high-impact actions SHALL additionally require step-up verification at an identity-assurance level equivalent to at least AAL2 of the current authoritative digital-identity guidance, performed at the moment of approval, not merely at session start.

5.4 Separation of duties for high-impact actions SHALL be technically enforced per MCC-800 clauses 4.3 and 4.4, including the override-governance requirements there (justification captured at use, immutable logging, oversight review, disablement before first issuance).

5.5 Privileged (administrative) access SHALL be: separated from ordinary user identities; granted just-in-time or time-bounded where technically feasible; fully session-logged; and prohibited from initiating or approving registry transactions.

5.6 Joiner, mover and leaver processes SHALL grant, adjust and revoke access on role change, with revocation within one business day of leaving and immediately on termination for cause; completion SHALL be logged (Record Retention Schedule class R13).

5.7 Credential recovery SHALL require out-of-band identity verification proportionate to the account's privileges (MCC-800 clauses 7.15 to 7.17 for registry accounts); recovery events SHALL be logged and notified to the account's registered contacts.

5.8 Remote and third-party access SHALL use the same identity, authentication and logging controls as internal access, with no unauthenticated administrative interface exposed.

6. Cryptography and key management

6.1 All data in transit over untrusted networks SHALL be encrypted using transport-security protocol versions and configurations that current good practice (clause 1.4) recommends, with deprecated protocol versions and cipher suites disabled; the versions actually deployed SHALL be recorded in the architecture specification and reviewed at least annually.

NOTE. This clause is the single suite-wide rule that replaces the divergent hard-coded "TLS 1.3 or later" and "TLS 1.2+" clauses the audit flagged (SYS-11). The Standard fixes the obligation — current-good-practice transport security, deprecations disabled, annual review — and the architecture specification records the moving selection, so the suite can never again disagree with itself about a protocol number.

6.2 All Programme data at rest in CONFIDENTIAL or RESTRICTED classifications, and all registry data, SHALL be encrypted using algorithms and key lengths current good practice recommends, recorded in the architecture specification.

6.3 Cryptographic keys and secrets SHALL be generated, stored and used in dedicated key-management facilities; keys SHALL never appear in source code, configuration files or logs.

6.4 Key management SHALL define, per key class: custody and access (dual control for root and signing keys), rotation schedule, revocation, backup and recovery, and destruction; key-management events SHALL be logged.

6.5 Integrity protections for the registry audit trail (MCC-800 clause 14.4) SHALL use cryptographic mechanisms whose keys or parameters are custodied so that no single person can regenerate or falsify the integrity chain.

7. Secure development and change management

7.1 All Programme software SHALL be developed under a documented secure development lifecycle: version control with complete history, mandatory peer code review, automated testing (including the machine-readable serial tests of MCC-800 Schedule 1 Part E for the registry), and dependency and vulnerability scanning in the build pipeline.

7.2 Changes SHALL follow the change-management classification and approval rules of MCC-800 Section 23 (for the registry) or an equivalent documented process (other systems), with rollback provisions and deployment traceability.

7.3 Production data SHALL NOT be used in development or test environments except minimised or de-identified; environments SHALL be segregated with no shared credentials.

7.4 Security requirements SHALL be defined before development of any new feature touching authentication, authorisation, unit states, balances, serials or public data, and verified before release.

8. Vulnerability and patch management

8.1 All systems SHALL be covered by automated vulnerability scanning at a defined cadence, and by monitoring of vendor and community security advisories for every deployed component.

8.2 Remediation SHALL meet defined service levels by severity; unless the architecture specification records stricter values, the defaults are: critical — mitigation within forty-eight hours and remediation within fourteen days; high — thirty days; medium — ninety days; low — next scheduled release. Deviations SHALL be handled as clause 3.5 exceptions.

8.3 Emergency security patches MAY be deployed under the emergency-change route (MCC-800 clause 23.5) with documentation and review within two business days.

9. Security testing and assurance

9.1 An independent penetration test of the registry platform SHALL be performed at least annually, and additionally before issuance is first enabled and after any material architectural change; findings SHALL be remediated per Section 8 and a summary published. No independent penetration test has been performed (Evidence Register ER-2026-001 §B5). No credit unit has been issued, and FD-2026-09-04 item 5 (recorded in the decision register as attested by the founder; no executed copy filed) resolved that no credit is issued before an independent penetration test has been completed and its findings addressed.

9.2 An independent security assessment covering this Standard's control set SHALL be performed at least annually (within the MCC-700 clause 4.8.3 audit or separately), with the summary published.

9.3 Security control evidence — test results, scan reports, review records, exercise outcomes — SHALL be filed in the Evidence Register against the control it evidences (QA-13).

9.4 A responsible-disclosure channel SHALL be published, with a commitment to acknowledge reports within five business days and not to pursue good-faith researchers.

10. Logging and monitoring

10.1 Security-relevant events — authentication successes and failures, permission changes, privileged actions, high-impact actions, data exports, configuration changes — SHALL be logged centrally, with clocks synchronised and log integrity protected against tampering.

10.2 Logs SHALL be monitored for indicators of compromise and for the registry-abuse patterns of MCC-800 clause 25.1, with alerting to the security function; alert handling SHALL be recorded.

10.3 Log retention follows the Record Retention Schedule (classes R2, R10, R11); this Standard sets no retention period.

11. Incident response

11.1 A documented incident-response plan SHALL define severity classes, roles and authority (including who may take systems offline), escalation paths, communication templates, evidence-preservation steps and recovery criteria; the plan SHALL be exercised at least annually.

11.2 Suspected incidents SHALL be triaged immediately; incidents affecting registry data integrity SHALL additionally trigger the reconciliation and flagging actions of MCC-800 clause 15.3.

11.3 Affected participants SHALL be notified without undue delay where an incident affects their accounts, units or data; critical participant notifications follow MCC-800 clause 16.5.

11.4 Personal-data breaches SHALL be assessed and notified to supervisory authorities and data subjects within the deadlines applicable data protection law imposes; the assessment SHALL be recorded even where no notification is required.

11.5 A post-incident review SHALL be completed within ten business days of closure (MCC-800 clause 20.6), with root cause, impact and remediation recorded, material incidents reported to the Registry Oversight Committee, and a summary published for incidents affecting registry integrity or availability.

12. Vendor and cloud controls

12.1 Suppliers processing Programme information SHALL be risk-assessed before engagement and periodically thereafter, proportionate to classification and criticality.

12.2 Supplier contracts SHALL bind: confidentiality; security obligations no weaker than this Standard for the information concerned; breach notification without undue delay; audit or assurance rights (independent assurance reports acceptable); data location and transfer constraints per applicable law; subprocessor transparency and flow-down; and return or destruction of data at exit.

12.3 Cloud services hosting the registry SHALL provide: geographic redundancy consistent with MCC-800 Section 20; tenant isolation; encryption per Section 6 with Programme-controlled key options where available; and exportability of all Programme data in open formats (supporting the escrow duty of MCC-800 clause 21.2).

12.4 A register of suppliers and their assessments SHALL be maintained; a supplier failure SHALL be handled under Section 11 and the continuity plan.

13. Personnel security and awareness

13.1 Personnel and contractors in roles with access to CONFIDENTIAL or RESTRICTED information, or with registry write access, SHALL be screened before appointment to the extent applicable law permits, proportionate to the role.

13.2 All personnel SHALL complete security awareness training at onboarding and at least annually; personnel in privileged or registry roles SHALL complete role-specific training covering this Standard, MCC-800 Sections 4 and 7, and social-engineering resistance.

13.3 Security responsibilities SHALL be stated in contracts and role descriptions, including the duty to report suspected incidents immediately.

14. Physical and environmental security

14.1 Physical access to any premises or equipment holding CONFIDENTIAL or RESTRICTED information SHALL be controlled and logged; for cloud-hosted systems this requirement is discharged through the provider assurances of clause 12.3.

14.2 End-user devices used for privileged or registry access SHALL be managed: encrypted at rest, screen-locked, patched per Section 8, and remotely wipeable.

15. Continuity interface

15.1 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.

15.2 Continuity arrangements for other Programme systems SHALL be documented proportionately to criticality and tested at least annually.

16. Amendments and entry into force

16.1 This Standard MAY be amended through the Tier 5 amendment route of the Document Hierarchy & Precedence Register, PROVIDED that no amendment weakens a control objective a higher-tier document relies on without the affected document owners being consulted and the change recorded in the changelog; clause 1.4 reviews that change only the recorded good-practice selection are architecture-specification updates, not amendments of this Standard.

16.2 This Standard 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.

16.3 Within ninety days of entry into force, each system owner SHALL file in the Evidence Register a conformity statement mapping each Section of this Standard to its implementation or to a clause 3.5 exception; for the registry, conformity of Sections 5, 6, 9, 10 and 11 is a precondition to lifting the issuance freeze (MCC-800 clause 27.4).

---

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