Procurement Auditability and Vendor Exit Act

By /

Procurement Auditability and Vendor Exit Act

Model Act Generated from the NSIR / CLIP Clean-System Framework

Long Title

An Act to establish auditability, transparency, public control, interoperability, service continuity, and exit requirements for procurement of high-impact public systems; to ensure that public authorities do not procure, deploy, or depend on vendor systems that cannot be inspected, audited, governed, secured, migrated, suspended, or exited; and to preserve lawful public administration, democratic accountability, public records, data sovereignty, and citizen redress in vendor-supported public systems.

Preamble

Whereas public authorities increasingly rely on vendors, contractors, consultants, cloud providers, software platforms, artificial intelligence systems, digital identity providers, case-management tools, payment systems, data processors, cybersecurity providers, analytics systems, and managed services to deliver public administration;

Whereas vendor systems may improve speed, technical capacity, accessibility, service delivery, security, and modernization;

Whereas vendor systems may also become hidden layers of public power when public authorities cannot inspect the system, access logs, understand configurations, audit decision pathways, preserve public records, correct data, review errors, migrate services, or exit the contract;

Whereas public authority cannot be lawfully outsourced beyond public accountability;

Whereas public authorities should not procure decision infrastructure they cannot audit;

Whereas citizens should not lose rights, benefits, services, reasons, appeal, data correction, or remedy because a public function has been outsourced, digitized, platformed, or embedded in proprietary systems;

Whereas artificial intelligence, automated workflows, cloud platforms, and integrated vendor systems can increase dependency, opacity, lock-in, and systemic risk if not governed by contract, law, auditability, and exit capability;

Whereas clean public systems require visible authority, public record control, vendor accountability, data portability, security review, incident reporting, interoperability, audit logs, service continuity, and decommissioning support;

Therefore, Parliament enacts as follows.

Part 1 — Short Title, Purpose, and Core Principles

1. Short Title

This Act may be cited as the Procurement Auditability and Vendor Exit Act.

2. Purpose

The purpose of this Act is to ensure that procurement, deployment, operation, renewal, and exit of vendor-supported high-impact public systems preserve:

  1. public control;
  2. auditability;
  3. lawful authority;
  4. public record integrity;
  5. data portability;
  6. interoperability;
  7. cybersecurity;
  8. privacy;
  9. service continuity;
  10. transparency of material vendor dependencies;
  11. meaningful review, appeal, and remedy;
  12. exit capability;
  13. democratic accountability.

3. Core Rule

A public authority shall not procure, deploy, materially rely on, renew, or expand a vendor-supported high-impact public system unless the contract, technical architecture, governance arrangement, and operating model preserve public audit rights, access to relevant records and logs, data portability, interoperability, incident reporting, security review, service continuity, decommissioning support, and practical exit capability.

4. Public Authority Non-Delegation Principle

A public authority may contract for tools, services, infrastructure, expertise, or technical capacity.

A public authority shall not contract away legal responsibility, public accountability, auditability, reasons, review, remedy, public record control, or the ability to govern the public system.

5. Vendor Transparency Principle

A vendor-supported public system shall be transparent enough for authorized public officials, auditors, oversight bodies, courts, tribunals, privacy commissioners, cybersecurity authorities, procurement authorities, and affected review processes to determine how the system operates, what records it holds, what data it uses, what changes were made, what errors occurred, and how the system can be corrected or exited.

6. Exit Capability Principle

A public authority shall not become dependent on a vendor-supported high-impact public system unless it maintains the legal, technical, operational, financial, contractual, and organizational ability to exit the system without unacceptable harm to rights, essential services, public records, security, public finance, accountability, or continuity of government.

7. No Accountability Laundering

A public authority shall not avoid responsibility for a public decision, service failure, data error, denial, delay, security breach, audit gap, or public harm by attributing the matter to a vendor, contractor, platform, cloud provider, model provider, subcontractor, software system, database, configuration, or proprietary process.

Part 2 — Definitions

8. Definitions

In this Act:

“affected person” means a person, household, organization, community, Indigenous government, business, public body, or legal entity whose rights, benefits, obligations, eligibility, access, service level, enforcement exposure, legal status, property, livelihood, privacy, liberty, safety, or public interest may be materially affected by a vendor-supported high-impact public system.

“audit access” means the lawful ability of authorized persons to inspect records, logs, configurations, documentation, decisions, data flows, model outputs, security records, incident records, vendor actions, subcontractor actions, system changes, and other materials necessary to verify compliance, legality, performance, security, public accountability, and system integrity.

“audit log” means a record of system activity sufficient to reconstruct material actions, access, changes, data use, automated steps, vendor actions, subcontractor actions, incidents, errors, overrides, decisions, appeals, corrections, and administrative operations.

“critical vendor system” means a vendor-supported high-impact public system whose failure, breach, outage, lock-in, data loss, audit failure, vendor withdrawal, insolvency, refusal, or non-performance could materially affect rights, essential services, public safety, emergency response, national security, critical infrastructure, public finance, public trust, or continuity of government.

“data portability” means the ability to export public records, data, metadata, audit logs, configuration information, and other necessary materials in a lawful, secure, documented, usable, and interoperable format.

“decommissioning support” means vendor cooperation, documentation, technical assistance, data export, record preservation, migration support, transition support, and shutdown assistance necessary to end use of a vendor system while preserving public obligations.

“exit capability” means the legal, contractual, technical, operational, financial, and organizational ability of a public authority to leave, replace, migrate from, suspend, or decommission a vendor-supported system without unacceptable harm to public records, service continuity, affected persons, auditability, security, or legal obligations.

“high-impact public system” means a public system that materially affects, or is reasonably likely to materially affect, rights, benefits, eligibility, access to essential services, legal status, enforcement, identity, privacy, public safety, housing, immigration, taxation, health, education, child welfare, social supports, procurement, public finance, emergency response, critical infrastructure, national security, or other significant public interests.

“interoperability” means the ability of systems to exchange, interpret, preserve, export, and use data, records, logs, configurations, or interfaces in a lawful, secure, documented, auditable, and portable manner.

“material subcontractor” means a subcontractor, supplier, cloud provider, model provider, data processor, analytics provider, security provider, infrastructure provider, or other third party whose services materially support a vendor-supported high-impact public system.

“public authority” means a department, ministry, agency, Crown corporation, tribunal, regulator, public office, municipality, delegated authority, contractor acting under public authority, or other body exercising public functions under law.

“public record control” means the authority and practical ability of a public authority to access, preserve, export, manage, audit, disclose, transfer, retain, correct, delete, or restrict public records in accordance with law, regardless of vendor involvement.

“responsible authority” means the public authority legally responsible for the procurement, contract, deployment, operation, review, suspension, renewal, exit, or decommissioning of a vendor-supported high-impact public system.

“service continuity” means the ability to maintain or restore public services, records, decisions, appeals, payments, benefits, emergency functions, essential operations, and public access during outage, breach, vendor failure, contract dispute, migration, suspension, exit, or decommissioning.

“vendor” means a contractor, supplier, platform provider, software provider, cloud provider, model provider, data processor, managed-service provider, consultant, integrator, subcontractor, or other non-public entity providing tools, systems, services, infrastructure, data processing, analytics, artificial intelligence, automation, case management, digital identity, cybersecurity, or operational support to a public authority.

“vendor-supported high-impact public system” means a high-impact public system materially designed, hosted, operated, configured, maintained, processed, analyzed, supported, secured, or controlled by a vendor.

Part 3 — Application and Scope

9. Application

This Act applies to every procurement, contract, renewal, extension, amendment, deployment, migration, integration, outsourcing, managed service, cloud service, artificial intelligence system, automated system, digital platform, database, case-management system, identity system, payment system, dashboard, records system, cybersecurity system, analytics system, or vendor-supported system used for a high-impact public system.

10. High-Impact Vendor Systems

A vendor-supported system shall be classified as high-impact where it materially supports or influences:

  1. eligibility for public benefits, permits, grants, licenses, housing, health, education, immigration, taxation, or social supports;
  2. access to essential public services;
  3. legal status, identity, liberty, mobility, livelihood, property, privacy, or safety;
  4. enforcement, inspection, investigation, sanctions, policing, corrections, child welfare, border administration, or compliance actions;
  5. public safety, emergency response, critical infrastructure, national security, or continuity of government;
  6. public procurement, public finance, public funds, or public assets above a prescribed threshold;
  7. appeals, complaints, human review, ombuds processes, tribunals, or administrative justice;
  8. digital identity, data-sharing, AI, automation, algorithmic scoring, or automated decision support;
  9. any other matter prescribed by regulation.

11. Critical Vendor Systems

A responsible authority shall designate a vendor-supported high-impact public system as critical where failure, outage, breach, non-performance, lock-in, data loss, audit failure, exit failure, vendor insolvency, or contract dispute could create serious harm to rights, essential services, safety, infrastructure, security, public finance, public trust, or continuity of government.

Critical vendor systems shall be subject to enhanced procurement review, cybersecurity review, continuity planning, independent audit, exit planning, and red-team testing.

12. Prohibition on Avoidance

A public authority shall not divide, relabel, outsource, subcontract, migrate, reclassify, embed, or procure a system in stages for the purpose of avoiding this Act.

13. Subcontractor and Supply-Chain Coverage

A vendor shall not use a material subcontractor in support of a high-impact public system unless the contract preserves public auditability, public record control, security, privacy, incident reporting, continuity, and exit rights in relation to the subcontractor.

Part 4 — Pre-Procurement Systems Integrity Review

14. Pre-Procurement Review Requirement

Before procuring or materially renewing a vendor-supported high-impact public system, the responsible authority shall complete a pre-procurement systems integrity review.

15. Contents of Pre-Procurement Review

The review shall identify:

  1. public purpose;
  2. legal authority;
  3. system boundary;
  4. affected persons;
  5. public decisions or services supported;
  6. data categories involved;
  7. AI, automation, algorithmic, or workflow components;
  8. public records involved;
  9. security and privacy requirements;
  10. auditability requirements;
  11. interoperability requirements;
  12. data portability requirements;
  13. service continuity requirements;
  14. vendor dependency risks;
  15. market alternatives;
  16. internal public capacity requirements;
  17. exit requirements;
  18. decommissioning requirements;
  19. risks of lock-in;
  20. risks to appeal, review, correction, and remedy.

16. Procurement Gate

A responsible authority shall not issue a solicitation, award a contract, or approve a material renewal for a vendor-supported high-impact public system unless the procurement documents include the auditability, public record control, security, privacy, portability, interoperability, continuity, and exit requirements required by this Act.

17. Public Interest Statement

For every critical vendor system, the responsible authority shall prepare a public interest statement explaining:

  1. why vendor involvement is necessary or justified;
  2. what public function is supported;
  3. what public authority remains accountable;
  4. what risks are created;
  5. how auditability is preserved;
  6. how public records are controlled;
  7. how exit capability is preserved;
  8. how affected persons retain rights to reasons, review, correction, and remedy.

18. Build-Buy-Partner Analysis

Before procuring a critical vendor system, the responsible authority shall assess whether the function should be built internally, procured externally, shared with another public authority, provided through open standards, or supported through a hybrid model.

The analysis shall consider:

  1. public capacity;
  2. cost;
  3. security;
  4. urgency;
  5. public record control;
  6. auditability;
  7. vendor dependency;
  8. exit capability;
  9. long-term maintenance;
  10. public accountability.

Part 5 — Mandatory Contract Terms

19. Mandatory Terms

A contract for a vendor-supported high-impact public system shall include terms preserving:

  1. public audit rights;
  2. access to relevant logs;
  3. system documentation;
  4. data documentation;
  5. configuration documentation;
  6. change logs;
  7. public record control;
  8. data portability;
  9. interoperability;
  10. cybersecurity testing;
  11. privacy compliance;
  12. incident reporting;
  13. subcontractor disclosure;
  14. material change notification;
  15. service continuity;
  16. decommissioning support;
  17. exit transition assistance;
  18. compliance with this Act.

20. Public Audit Rights

The contract shall provide the responsible authority and authorized reviewers with audit access sufficient to verify:

  1. legality;
  2. security;
  3. privacy;
  4. performance;
  5. data use;
  6. data sharing;
  7. record preservation;
  8. system changes;
  9. vendor actions;
  10. subcontractor actions;
  11. compliance with service levels;
  12. compliance with public accountability obligations;
  13. compliance with this Act.

21. Access to Logs

The contract shall require the vendor to preserve and provide access to logs sufficient to reconstruct:

  1. system access;
  2. vendor access;
  3. subcontractor access;
  4. data access;
  5. data modification;
  6. data deletion;
  7. configuration changes;
  8. system changes;
  9. security events;
  10. incidents;
  11. automated actions;
  12. AI or algorithmic outputs where applicable;
  13. administrative actions materially affecting public services or decisions.

22. Documentation

The contract shall require documentation sufficient for public operation, review, audit, migration, continuity, and exit.

Documentation shall include, where applicable:

  1. system architecture;
  2. data model;
  3. data dictionary;
  4. APIs and interfaces;
  5. configuration settings;
  6. access-control model;
  7. security controls;
  8. privacy controls;
  9. workflow rules;
  10. algorithmic or AI system documentation;
  11. model cards or equivalent documentation;
  12. update procedures;
  13. incident procedures;
  14. backup and recovery procedures;
  15. decommissioning procedures.

23. Public Record Control

The contract shall state that public records remain under public control.

The vendor shall not prevent lawful access, preservation, export, disclosure, correction, deletion, restriction, transfer, audit, or retention of public records.

24. Data Portability

The contract shall require the vendor to support lawful export of public records, data, metadata, audit logs, configuration information, and other materials necessary for audit, continuity, migration, appeal, legal review, and decommissioning.

25. Interoperability

The contract shall require interoperability sufficient to prevent avoidable lock-in, preserve public records, support lawful integration, enable competition where appropriate, and permit exit or replacement.

26. Security Testing

The contract shall require vendor cooperation with security testing, vulnerability assessment, penetration testing, red-team testing, incident investigation, supply-chain risk review, and other cybersecurity assurance processes required by the responsible authority.

27. Incident Reporting

The contract shall require the vendor to report material incidents within prescribed timelines.

Material incidents include:

  1. security breach;
  2. privacy breach;
  3. service outage;
  4. data loss;
  5. audit-log failure;
  6. unauthorized access;
  7. unauthorized subcontractor access;
  8. unauthorized data sharing;
  9. material performance failure;
  10. material system error;
  11. unapproved configuration change;
  12. inability to export records;
  13. inability to support appeal or review;
  14. failure affecting service continuity;
  15. any other incident prescribed by regulation.

28. Subcontractor Disclosure

The contract shall require disclosure of all material subcontractors and shall prohibit undisclosed material subcontracting.

29. Material Change Notification

The contract shall require prior notice and approval for material changes to:

  1. system architecture;
  2. data storage;
  3. data processing;
  4. security controls;
  5. subcontractors;
  6. hosting location;
  7. AI or algorithmic components;
  8. configuration;
  9. service levels;
  10. audit access;
  11. interoperability;
  12. exit support.

30. Decommissioning Support

The contract shall require the vendor to provide decommissioning support, including data export, records preservation, migration assistance, continuity support, knowledge transfer, system shutdown support, and certification of deletion or return where required.

31. Exit Rights

The contract shall preserve the responsible authority’s right to exit the vendor relationship for cause, non-performance, loss of auditability, security risk, privacy risk, legal non-compliance, unacceptable lock-in, public interest necessity, or other prescribed grounds.

Part 6 — Prohibited Contract Terms

32. Prohibited Terms

A contract for a vendor-supported high-impact public system shall not include terms that:

  1. prevent public audit;
  2. prevent access to relevant logs;
  3. prevent public record control;
  4. prevent lawful disclosure to authorized oversight bodies;
  5. prevent appeal, review, or remedy;
  6. prevent data portability;
  7. prevent interoperability necessary for exit;
  8. prevent security testing;
  9. prevent incident reporting;
  10. permit undisclosed material subcontracting;
  11. permit undisclosed secondary use of public data;
  12. permit vendor use of public data for model training without lawful authority and express authorization;
  13. prevent decommissioning;
  14. impose punitive lock-in inconsistent with public interest;
  15. defeat the purpose of this Act.

33. Unenforceability

A prohibited term is unenforceable to the extent of the inconsistency with this Act.

34. No Confidentiality Against Accountability

Confidentiality, trade secret, commercial sensitivity, intellectual property, security, or contractual language shall not prevent authorized audit, legal review, privacy review, cybersecurity review, appeal review, public records review, oversight, or investigation.

Part 7 — Vendor Auditability and Oversight

35. Auditability Duty

A vendor supporting a high-impact public system shall cooperate with lawful audits, reviews, investigations, inspections, and oversight processes.

36. Authorized Reviewers

Audit access may be exercised by:

  1. responsible public authority;
  2. auditor general or equivalent audit body;
  3. privacy commissioner or equivalent privacy body;
  4. cybersecurity authority;
  5. procurement authority;
  6. ombuds institution;
  7. tribunal or court where relevant;
  8. legislative committee where authorized;
  9. independent reviewer appointed under law or contract;
  10. other authorized oversight body.

37. Audit Scope

An audit may examine:

  1. system design;
  2. system operation;
  3. data flows;
  4. access logs;
  5. security controls;
  6. privacy controls;
  7. service levels;
  8. public record control;
  9. incident handling;
  10. subcontractor performance;
  11. AI or algorithmic components;
  12. system changes;
  13. exit readiness;
  14. compliance with contract;
  15. compliance with this Act.

38. Audit Cooperation

A vendor shall provide timely access to records, personnel, systems, logs, documentation, testing environments, and explanations reasonably necessary for authorized audit.

39. Audit Obstruction

A vendor shall not obstruct, delay, conceal, destroy, alter, or prevent lawful audit access.

40. Audit Findings

Where an audit identifies material non-compliance, the responsible authority shall require a corrective action plan or take appropriate action, including suspension, remediation, contract enforcement, non-renewal, termination, or exit.

Part 8 — Public Records, Data, and Knowledge Transfer

41. Public Records

Public records held, processed, stored, generated, or managed by a vendor remain public records subject to applicable public records, access, privacy, audit, and legal obligations.

42. Records Inventory

A contract for a vendor-supported high-impact public system shall require a records inventory identifying:

  1. record categories;
  2. data categories;
  3. metadata;
  4. audit logs;
  5. configuration records;
  6. decision records;
  7. appeal or review records;
  8. retention requirements;
  9. export formats;
  10. responsible custodians.

43. Knowledge Transfer

A vendor shall provide knowledge transfer sufficient to allow the responsible authority or successor provider to operate, maintain, audit, migrate, or decommission the system.

44. Data Return and Deletion

Upon termination, expiry, suspension, migration, or exit, the vendor shall return, export, delete, restrict, or preserve data as directed by the responsible authority and required by law.

45. Certification

The vendor shall certify completion of data return, deletion, restriction, or preservation requirements, subject to audit.

Part 9 — Service Continuity and Resilience

46. Service Continuity Requirement

A responsible authority shall maintain a service continuity plan for each critical vendor system.

47. Contents of Service Continuity Plan

A service continuity plan shall identify:

  1. essential public services supported;
  2. responsible officials;
  3. vendor obligations;
  4. backup processes;
  5. alternative service pathways;
  6. manual or assisted processes;
  7. data backup and restoration;
  8. audit-log preservation;
  9. public communication;
  10. affected-person notice;
  11. appeal and remedy continuity;
  12. emergency escalation;
  13. recovery time objective;
  14. recovery point objective;
  15. post-incident review.

48. Vendor Failure

The responsible authority shall prepare for vendor failure, including:

  1. insolvency;
  2. contract dispute;
  3. cyber incident;
  4. system outage;
  5. withdrawal from market;
  6. acquisition or ownership change;
  7. material subcontractor failure;
  8. failure to meet service levels;
  9. refusal to provide audit access;
  10. inability to support exit.

49. Continuity Testing

A critical vendor system shall be subject to periodic continuity testing, including backup restoration, failover, manual fallback, data export, and exit simulation where appropriate.

Part 10 — Exit Capability and Decommissioning

50. Exit Plan Requirement

A responsible authority shall maintain an exit plan for every vendor-supported high-impact public system.

51. Contents of Exit Plan

An exit plan shall identify:

  1. exit triggers;
  2. responsible authority;
  3. contractual exit rights;
  4. public records affected;
  5. data export process;
  6. metadata export process;
  7. audit-log preservation;
  8. configuration export or documentation;
  9. successor system or provider;
  10. internal capacity requirements;
  11. service continuity measures;
  12. affected-person risks;
  13. public communication plan;
  14. vendor cooperation obligations;
  15. decommissioning process;
  16. deletion or preservation certification;
  17. timeline for exit;
  18. post-exit review.

52. Exit Triggers

Exit may be triggered by:

  1. material breach;
  2. loss of auditability;
  3. cybersecurity risk;
  4. privacy risk;
  5. unlawful data use;
  6. unacceptable lock-in;
  7. repeated service failure;
  8. vendor insolvency;
  9. public interest necessity;
  10. failure to support appeal, remedy, or public records;
  11. unapproved material system change;
  12. failure to comply with this Act.

53. Exit Simulation

A critical vendor system shall undergo periodic exit simulation or exit-readiness testing.

Testing shall assess whether the responsible authority can export data, preserve records, maintain service continuity, migrate to another system, and terminate the vendor relationship without unacceptable harm.

54. Decommissioning

A vendor-supported high-impact public system shall be decommissioned where repair is not feasible, lawful operation is impossible, or continued use would create unacceptable risk to rights, essential services, public records, security, privacy, auditability, public finance, public trust, or democratic accountability.

55. No Hostage Systems

A public authority shall not permit a vendor-supported high-impact public system to become a hostage system.

A hostage system exists where the public authority cannot practically audit, migrate, suspend, replace, or exit the system without unacceptable harm because of vendor lock-in, inaccessible records, proprietary barriers, missing documentation, excessive exit costs, or lack of public capacity.

Part 11 — AI, Automation, and Algorithmic Vendor Systems

56. Enhanced Requirements for Vendor AI Systems

A vendor-provided AI, algorithmic, automated decision, scoring, triage, risk, generative, or decision-support system used in high-impact public administration shall comply with enhanced requirements.

57. Required AI Vendor Documentation

The vendor shall provide documentation sufficient to assess:

  1. intended use;
  2. prohibited uses;
  3. data categories;
  4. training, tuning, testing, or configuration information appropriate to the system;
  5. evaluation results;
  6. known limitations;
  7. failure modes;
  8. human oversight requirements;
  9. audit logs;
  10. model or system change process;
  11. security controls;
  12. incident reporting;
  13. decommissioning process.

58. No Black-Box Public Decisions

A public authority shall not deploy a vendor AI or algorithmic system in a high-impact public decision pathway if authorized reviewers cannot obtain sufficient information to assess legality, auditability, appealability, data use, human review, error, and system performance.

59. Model Updates and Configuration Changes

A vendor shall not make material changes to a high-impact AI or algorithmic system without notice, approval, testing, documentation, and auditability.

60. Vendor Model Training

A vendor shall not use public data for model training, fine-tuning, analytics development, product improvement, or secondary commercial purposes unless expressly authorized by law and contract, subject to privacy, security, public purpose, audit, and public record safeguards.

61. Human Review Support

A vendor AI system must support meaningful human review by preserving records, outputs, inputs where appropriate, confidence indicators where applicable, version information, system role, and explanations sufficient for affected-person review, audit, appeal, and remedy.

Part 12 — Subcontractors, Supply Chain, and Ownership Changes

62. Subcontractor Approval

A vendor shall not use a material subcontractor without prior disclosure and approval by the responsible authority.

63. Subcontractor Obligations

A material subcontractor shall be bound by obligations equivalent to those imposed on the vendor where necessary to preserve auditability, security, privacy, public record control, service continuity, and exit capability.

64. Supply-Chain Risk Assessment

A responsible authority shall conduct a supply-chain risk assessment for critical vendor systems.

The assessment shall include:

  1. ownership;
  2. jurisdiction;
  3. subcontractors;
  4. hosting location;
  5. data access;
  6. security posture;
  7. dependency concentration;
  8. geopolitical or legal exposure where relevant;
  9. continuity risk;
  10. exit risk.

65. Ownership Change Notice

A vendor supporting a critical public system shall notify the responsible authority of any material ownership, control, merger, acquisition, insolvency, restructuring, or jurisdictional change that could affect service, security, privacy, auditability, or exit capability.

66. Right to Reassess

A material subcontractor change, ownership change, hosting change, or supply-chain change shall permit the responsible authority to reassess the contract, require mitigation, suspend deployment, or initiate exit where appropriate.

Part 13 — Performance, Service Levels, and Public Outcomes

67. Service-Level Requirements

A contract for a vendor-supported high-impact public system shall include service-level requirements tied to public purpose, service continuity, accessibility, security, incident response, record access, audit cooperation, and exit support.

68. Public Outcome Integrity

A public authority shall not rely solely on vendor performance metrics that measure activity, uptime, throughput, or ticket closure where such metrics fail to measure public outcomes, appealability, correction, accessibility, fairness, or service quality.

69. Performance Reporting

A vendor shall provide performance reporting sufficient for the responsible authority to assess:

  1. service levels;
  2. outages;
  3. incidents;
  4. support response;
  5. accessibility failures;
  6. record access;
  7. audit cooperation;
  8. data export readiness;
  9. security issues;
  10. public-service impacts.

70. Metric Distortion

Where vendor performance metrics create incentives to deny, delay, close, misroute, suppress, or undercount public-service needs, the responsible authority shall revise the metrics or require corrective action.

Part 14 — Public Transparency and Vendor Register

71. Vendor Systems Register

The government shall establish and maintain a public register of vendor-supported high-impact public systems.

72. Contents of Register

The register shall include:

  1. system name;
  2. responsible authority;
  3. vendor name;
  4. material subcontractors where disclosure is lawful;
  5. public purpose;
  6. legal authority;
  7. affected population;
  8. services or decisions supported;
  9. high-impact or critical classification;
  10. data categories involved;
  11. AI or automation involvement;
  12. audit status;
  13. cybersecurity review status;
  14. privacy review status;
  15. service continuity status;
  16. exit plan status;
  17. contract start and end dates where disclosure is lawful;
  18. date of last review;
  19. next review date.

73. Protected Information

Information may be withheld from the public register only where disclosure would create a serious and demonstrable risk to national security, cybersecurity, privacy, personal safety, law enforcement, lawful confidentiality, or legitimate commercial confidentiality.

Where information is withheld, the responsible authority shall publish the highest safe level of public explanation and maintain a restricted record for authorized review.

74. Vendor Dependency Dashboard

The government shall maintain a vendor dependency dashboard.

The dashboard shall include indicators for:

  1. number of vendor-supported high-impact systems;
  2. number of critical vendor systems;
  3. systems with completed auditability review;
  4. systems with exit plans;
  5. systems with unresolved lock-in risk;
  6. systems with unresolved auditability gaps;
  7. systems with unresolved public record control gaps;
  8. systems with recent incidents;
  9. systems with subcontractor risk;
  10. systems scheduled for renewal;
  11. systems scheduled for exit or decommissioning.

Part 15 — Incident Reporting and Corrective Action

75. Vendor Incident Reporting Duty

A vendor and responsible authority shall report material incidents involving vendor-supported high-impact public systems.

76. Reportable Incidents

A reportable incident includes:

  1. security breach;
  2. privacy breach;
  3. service outage;
  4. data loss;
  5. unauthorized access;
  6. unauthorized data sharing;
  7. unauthorized subcontractor involvement;
  8. audit-log failure;
  9. inability to reconstruct a decision or transaction;
  10. unapproved material system change;
  11. vendor refusal to provide audit access;
  12. failure to support appeal, correction, or remedy;
  13. failure to meet critical service levels;
  14. data export failure;
  15. vendor insolvency or continuity risk;
  16. any other prescribed incident.

77. Incident Response Plan

A responsible authority shall maintain an incident response plan for every critical vendor system.

The plan shall identify:

  1. incident detection;
  2. responsible officials;
  3. vendor obligations;
  4. containment process;
  5. affected-person notification where appropriate;
  6. public communication;
  7. service continuity;
  8. data preservation;
  9. audit-log preservation;
  10. emergency suspension;
  11. contractual remedies;
  12. post-incident review;
  13. systemic correction.

78. Public Reporting

Material incidents shall be reported publicly unless disclosure would create a serious and demonstrable risk to national security, cybersecurity, privacy, law enforcement, personal safety, or lawful confidentiality.

Where full disclosure is restricted, the responsible authority shall publish the highest safe level of public explanation.

Part 16 — Independent Review, Red-Team Testing, and Public Challenge

79. Independent Review

A critical vendor system shall be subject to independent review by persons with appropriate expertise in law, procurement, public administration, systems engineering, cybersecurity, privacy, data governance, audit, accessibility, public records, and the affected domain.

80. Red-Team Review

A critical vendor system shall be subject to red-team review.

The review shall ask:

  1. how the vendor system could fail;
  2. how the public authority could become locked in;
  3. how public records could become inaccessible;
  4. how audit access could fail;
  5. how appeal, correction, or remedy could be blocked;
  6. how data could be misused;
  7. how subcontractors could create hidden risk;
  8. how a cyber incident could disrupt service;
  9. how exit could fail;
  10. how the system could resist correction.

81. Public Challenge Process

The responsible authority shall establish a process through which affected persons, civil society, journalists, public servants, auditors, experts, Indigenous governments, competing suppliers, public bodies, and other affected parties may submit evidence of vendor lock-in, auditability gaps, security risks, privacy risks, public record failures, exit failures, procurement defects, or service-continuity concerns.

Part 17 — Enforcement, Compliance, and Remedies

82. Oversight Body

An authorized oversight body shall monitor compliance with this Act.

The oversight body may be established by regulation or assigned to an existing public authority with appropriate independence, expertise, and legal powers.

83. Powers of Oversight Body

The oversight body may:

  1. require records;
  2. inspect contracts;
  3. inspect audit logs;
  4. inspect vendor documentation;
  5. review procurement files;
  6. investigate incidents;
  7. require corrective action;
  8. require contract amendment where lawful;
  9. order suspension of unsafe deployment;
  10. require exit planning;
  11. require independent review;
  12. refer matters to tribunals, courts, auditors, privacy commissioners, cybersecurity authorities, procurement authorities, competition authorities, human rights bodies, or law enforcement where appropriate.

84. Compliance Orders

The oversight body may issue a compliance order requiring a responsible authority or vendor to:

  1. provide audit access;
  2. provide logs;
  3. provide documentation;
  4. repair public record control;
  5. repair data portability;
  6. repair interoperability;
  7. repair security deficiencies;
  8. report an incident;
  9. disclose material subcontractors;
  10. prepare or update an exit plan;
  11. prepare a service continuity plan;
  12. suspend unsafe operation;
  13. report on corrective action.

85. Contractual Remedies

A contract for a vendor-supported high-impact public system shall preserve remedies for non-compliance, including:

  1. cure rights;
  2. service credits where appropriate;
  3. withholding of payment;
  4. mandatory remediation;
  5. audit escalation;
  6. suspension;
  7. termination for cause;
  8. transition assistance;
  9. indemnity where lawful;
  10. debarment or procurement exclusion where prescribed by law.

86. Individual Remedy

Where an affected person suffers material harm due to vendor-related failure to provide reasons, review, correction, appeal, remedy, security, privacy, public records, auditability, or service continuity required by law, the affected person may seek remedy through the applicable review, appeal, tribunal, court, ombuds, privacy, human rights, administrative, or oversight process.

87. Whistleblower Protection

No person shall suffer retaliation for reporting vendor concealment, audit obstruction, unsafe deployment, data misuse, public record failure, cybersecurity risk, privacy risk, subcontractor risk, lock-in risk, exit failure, procurement defect, or serious public-system risk in good faith.

Part 18 — Security, Confidentiality, and Bounded Accountability

88. Protected Information

Nothing in this Act requires public disclosure of information where disclosure would create a serious and demonstrable risk to national security, cybersecurity, privacy, personal safety, law enforcement, legally privileged information, or lawful confidentiality.

89. Bounded Accountability

Where information cannot be made public, the responsible authority shall provide:

  1. a public summary at the highest safe level of abstraction;
  2. a restricted record for authorized reviewers;
  3. audit access sufficient to verify legality, accountability, and compliance;
  4. written reasons for withholding public disclosure.

90. No Secrecy Without Review

Confidentiality shall not eliminate the requirement for authorized audit, legal review, privacy review, cybersecurity review, appeal review, public records review, oversight, and accountability.

Part 19 — Regulations

91. Regulations

The Governor in Council may make regulations:

  1. prescribing high-impact vendor systems;
  2. prescribing critical vendor systems;
  3. establishing mandatory contract terms;
  4. establishing prohibited contract terms;
  5. establishing auditability standards;
  6. establishing data portability standards;
  7. establishing interoperability standards;
  8. establishing service continuity requirements;
  9. establishing exit plan requirements;
  10. establishing incident reporting thresholds;
  11. establishing subcontractor disclosure requirements;
  12. establishing vendor register requirements;
  13. establishing dashboard indicators;
  14. establishing cybersecurity and privacy review requirements;
  15. establishing phased implementation timelines;
  16. exempting systems where equivalent or stronger protections exist.

92. No Regulation May Defeat Purpose

No regulation made under this Act shall defeat the purpose of preserving public auditability, public record control, data portability, interoperability, service continuity, vendor accountability, and exit capability for high-impact public systems.

Part 20 — Statutory Review, Pilot Phase, and Coming into Force

93. Statutory Review

A committee of Parliament shall review this Act within three years after coming into force and every five years thereafter.

The review shall examine:

  1. whether the Act improves procurement auditability;
  2. whether it reduces vendor lock-in;
  3. whether it improves public record control;
  4. whether it improves data portability;
  5. whether it improves interoperability;
  6. whether it improves service continuity;
  7. whether it improves exit capability;
  8. whether it strengthens security and privacy;
  9. whether it creates unnecessary procurement burden;
  10. whether amendments are required.

94. Pilot Phase

This Act shall be implemented through a pilot phase applying first to prescribed high-impact vendor-supported systems, including:

  1. digital identity systems;
  2. public benefit portals;
  3. public AI or automated decision systems;
  4. case-management systems affecting rights, benefits, enforcement, or essential services;
  5. cloud-hosted critical public systems;
  6. public data-sharing platforms;
  7. procurement or grant-management systems;
  8. emergency-response digital systems;
  9. public finance or payment systems;
  10. cybersecurity-managed services supporting critical public systems.

95. Coming into Force

This Act comes into force on a day fixed by order of the Governor in Council.

Different provisions may come into force on different days.

Schedule A — Vendor Auditability Assessment Template

A vendor auditability assessment shall include:

  1. system name;
  2. responsible authority;
  3. vendor name;
  4. material subcontractors;
  5. public purpose;
  6. legal authority;
  7. affected population;
  8. public services or decisions supported;
  9. data categories involved;
  10. public records involved;
  11. AI or automation involvement;
  12. audit rights;
  13. access to logs;
  14. documentation available;
  15. cybersecurity review;
  16. privacy review;
  17. data portability;
  18. interoperability;
  19. service continuity;
  20. exit plan;
  21. decommissioning support;
  22. failure-mode register;
  23. repair sequence.

Schedule B — Mandatory High-Impact Vendor Contract Clauses

A contract for a vendor-supported high-impact public system shall include clauses addressing:

  1. public audit rights;
  2. access to relevant logs;
  3. documentation;
  4. public record control;
  5. data portability;
  6. interoperability;
  7. cybersecurity cooperation;
  8. privacy compliance;
  9. incident reporting;
  10. subcontractor disclosure;
  11. material change notification;
  12. service continuity;
  13. exit support;
  14. decommissioning support;
  15. data return, deletion, or preservation;
  16. compliance with public law obligations;
  17. survival of audit and record obligations after termination.

Schedule C — Exit Plan Template

An exit plan shall identify:

  1. system name;
  2. responsible authority;
  3. vendor;
  4. public services affected;
  5. public records affected;
  6. data export process;
  7. metadata export process;
  8. audit-log preservation;
  9. configuration export or documentation;
  10. successor system or provider;
  11. internal capacity requirements;
  12. service continuity pathway;
  13. affected-person risk assessment;
  14. public communication process;
  15. vendor cooperation obligations;
  16. decommissioning process;
  17. deletion or preservation certification;
  18. timeline;
  19. test date;
  20. review date.

Schedule D — Vendor Failure Mode Register

A vendor failure-mode register shall identify:

  1. failure mode;
  2. affected public system;
  3. affected population;
  4. triggering condition;
  5. likely harm;
  6. severity;
  7. probability;
  8. detectability;
  9. responsible authority;
  10. vendor responsibility;
  11. existing control;
  12. missing control;
  13. repair action;
  14. exit trigger;
  15. deadline;
  16. status;
  17. review date.

Failure modes may include:

  1. vendor lock-in;
  2. inaccessible records;
  3. missing logs;
  4. undocumented configuration;
  5. undisclosed subcontractor;
  6. unauthorized data use;
  7. service outage;
  8. cyber breach;
  9. privacy breach;
  10. data export failure;
  11. audit obstruction;
  12. support withdrawal;
  13. vendor insolvency;
  14. ownership change;
  15. model update without notice;
  16. inability to decommission.

Schedule E — Public Vendor System Summary

A citizen-readable vendor system summary shall answer:

  1. What public system uses a vendor?
  2. Which public authority remains responsible?
  3. What does the vendor system do?
  4. Who may be affected?
  5. What public services or decisions does it support?
  6. What data categories are involved?
  7. Does it use AI or automation?
  8. How is the system audited?
  9. How are public records controlled?
  10. How are privacy and cybersecurity protected?
  11. How can affected persons obtain reasons, review, correction, or remedy?
  12. Can the public authority exit the vendor system?
  13. When will the system next be reviewed?

Schedule F — Procurement Gate Checklist

Before awarding or renewing a high-impact vendor contract, the responsible authority shall confirm:

  1. the public purpose is defined;
  2. legal authority is identified;
  3. system map is prepared;
  4. data-flow map is prepared where applicable;
  5. public record control is preserved;
  6. audit rights are included;
  7. logs are accessible;
  8. documentation is sufficient;
  9. cybersecurity review is complete;
  10. privacy review is complete;
  11. data portability is required;
  12. interoperability is required;
  13. subcontractors are disclosed;
  14. incident reporting is required;
  15. service continuity plan exists;
  16. exit plan exists;
  17. decommissioning support is required;
  18. appeal, review, correction, and remedy are not impaired.

Final Standard

The Procurement Auditability and Vendor Exit Act exists because public authority cannot become dependent on systems it cannot inspect, govern, or leave.

A government may buy tools.

It may not buy blindness.

It may buy technical capacity.

It may not outsource accountability.

It may use vendor systems.

It may not become trapped inside them.

The standard is simple:

No public authority should procure high-impact public infrastructure it cannot audit, control, migrate, suspend, or exit.

 

Project Page: AI Does Not Fix Government. It Amplifies It (Part 1) https://x.com/SkillsGapTrain/status/2065348053645861271

Disclaimer: This is an open-source educational system that is being developed for learning, research, frontier systems engineering and prototyping, intended to help students, teachers, public-sector builders, policy analysts, political leaders, corporate leaders and responsible organizations explore next-generation governance systems for humanity; it is not legal advice, policy authority, certification, or deployment-ready public infrastructure. Executive Summary of Audit of current development status is located at bottom of Part 3 of Project Page.

Scroll to Top