A Federal Technical Reserve Act?

March 11, 2025

A Federal Technical Reserve Act?

David M. Berry

The recent attempts to gain privileged access to Treasury payment systems have revealed a troubling vulnerability at the heart of democratic governance given that critical computational infrastructure that underpins essential government functions remains largely unprotected from rapid repurposing for partisan or authoritarian ends (Berry 2025). The Department of Government Efficiency's (DOGE) efforts to modify core payment systems demonstrate how computational systems have become fundamental to the exercise of state power, yet lack the institutional safeguards commensurate with their importance.

In this article I therefore suggest a possible solution to this issue by examining a statutory framework modelled after the Federal Reserve System to protect critical computational infrastructure from capture or abuse while maintaining operational ability (see Appendix 1 for an American proposal, and Appendix 2, for the UK proposal). Just as the Federal Reserve was designed to insulate monetary policy from short-term political pressures through institutional independence and expertise, I aim to explore whether we need similar protections for the computational systems that have become essential to modern governance.

Vulnerability of Critical Computational Infrastructure

Critical governmental systems, particularly those processing payments, managing records, or controlling access to essential services, represent new vectors for potential authoritarian control (Berry 2025). As we have seen in the case of Treasury payment systems, privileged access to modify source code can potentially enable unilateral redirection or freezing of congressionally authorised payments, the bypassing of legally mandated processes for funds allocation, the implementation of targeting capabilities that could be weaponised against political opponents, and the creation of backdoor access that circumvents normal security protocols (Tankus 2025, 2025b, 2025c).

The current landscape therefore seems to offer only limited oversight, inadequate procedural safeguards, and virtually no standardised processes for evaluating the constitutional implications of computer system modifications. Agency heads can be replaced, civil servants pressured, and technical experts sidelined or "retired", with few institutional barriers preventing the rapid repurposing of these systems.

Most concerningly, the technical complexity and specialised knowledge requirements of these systems mean that few people understand their full implications, creating an asymmetry where those with technical access have disproportionate and largely unchecked power (Berry 2025).

The Federal Reserve Model for Computational Infrastructure

I suggest that the Federal Reserve System offers an interesting model for addressing these vulnerabilities. Created in 1913 to provide stability to the monetary system and insulate it from short-term political pressures, the Fed achieves this through several key design features that I believe could be used for protecting computational infrastructure. Some of these are drawn from a proposed Federal Technical Reserve include long, staggered terms of 14 years for Board Governors that transcend political cycles which ensure no single administration can quickly reshape the institution; independence in technical decision-making while maintaining democratic accountability; expertise requirements that prioritise technical qualifications over political connections; "for cause" removal protections that prevent arbitrary dismissal of board members; and procedural rigour in decision-making processes.

I suggest that adapting these principles to critical computational infrastructure would create institutional friction against authoritarian capture while preserving the operational flexibility needed for routine and legitimate system maintenance and development.

The Federal Technical Reserve Act

The Federal Technical Reserve Act I am proposing (see below in Appendix 1, but also see in Appendix 2, a similar proposal for a UK Office for Technical Responsibility) would therefore establish a Federal Technical Reserve System with similar structural protections to the Federal Reserve, but tailored to the specific challenges of computational systems. As mentioned above, I outline an independent Board of Governors with 14-year staggered terms and technical expertise requirements, working through specialised Technical Divisions organised by system type rather than geography. The legislation I propose would implement a risk-based classification system, inspired by the EU AI Act, that imposes graduated time constraints and review requirements based on the potential impact of system modifications. I believe it is crucial to also include explicit challenge procedures allowing for review of high-risk changes, alongside technical transparency requirements including cryptographic signing of changes and secure code repositories.

The aim of this framework is to normalise and standardise changes to critical systems through a risk-tiered approach. In this model, for example, routine maintenance and security updates would proceed with minimal friction, whilst higher-risk changes would trigger increasing levels of review, documentation, and time constraints. Changes classified as "unacceptable risk" would be statutorily prohibited except under extraordinary circumstances, which would require multi-branch approval and specific sunset provisions. Whilst of itself this might not stop concerted action to dissemble or undermine critical computational systems, it would introduce an element of procedural certainty, legal accountability and, perhaps most importantly, slow down high risk changes to critical systems.

Strengthening Democratic Governance

Although I believe that a statutory approach would help strengthen democratic norms and conventions by creating institutional resilience against authoritarian capture through procedural safeguards that slow down potentially dangerous modifications, it cannot be the full response. It would ensure technical accountability through documentation requirements and audit trails that make system changes visible to oversight bodies. It would also foster a deliberative process that allows for thoughtful consideration of high-risk changes rather than hasty implementation, whilst also preserving technical expertise through structures that protect institutional knowledge and professional norms. Perhaps most importantly, it would enhance democratic legitimacy by establishing clear statutory authority and transparency for system modifications to these critical systems. But action from other agencies and political actors would be crucial, perhaps most importantly Congress and the Judiciary.

Conclusion

I argue that the attempted capture of the American government Treasury payment systems serves as a warning that our democratic institutions have not kept pace with the growing importance of computational infrastructure (Berry 2014, 2025). Just as the American Founders created checks and balances to prevent the concentration of power, I suggest we must now create institutional safeguards against the weaponisation of critical computational systems in our polities.

The Federal Reserve model suggested here, adapted to the unique challenges of computational infrastructure, offers a possible template for establishing these protections. Through careful institutional design, I believe we can ensure that these essential systems remain responsive to democratic governance rather than potential instruments of authoritarian control. The proposed Federal Technical Reserve Act below is not just a technical solution, but a recognition that the infrastructure of modern governance requires new forms of institutional protection to preserve democratic values in a digital age.

Now, jump to

Appendix 1 for an American proposal
Appendix 2 for the UK proposal

** Headline image generated using DALL-E in March 2025. The prompt used was: "A high-definition, photojournalism-style image of the U.S. Congress in session, with politicians actively debating and voting on a bill titled 'Federal Technical Reserve Act.' The scene captures the grandeur of the legislative chamber, with lawmakers in suits engaging in discussions and casting votes. A large electronic board displays the bill's name and voting results. The image is taken from a press photographer's perspective, with realistic lighting, depth of field, and natural composition. Reporters and citizens watch from the gallery, adding to the historical significance of the moment." Due to the probabilistic way in which these images are generated, future images generated using this prompt are unlikely to be the same as this version.

Bibliography

Berry, D. M. (2014) Critical Theory and the Digital. New York: Bloomsbury.

Berry, D.M. (2025) ‘API: Authoritarian Programming Interface’, Stunlaw. Available at: https://stunlaw.blogspot.com/2025/02/api-authoritarian-programming-interface.html

Tankus, N. (2025) Elon Musk Wants to Get Operational Control of the Treasury’s Payment System. This Could Not Possibly Be More Dangerous, Notes on the Crises. Available at: https://www.crisesnotes.com/elon-musk-wants-to-get-operational-control-of-the-treasurys-payment-system-this-could-not-possibly-be-more-dangerous/ (Accessed: 6 February 2025).

Tankus, N. (2025b) Day Five of the Trump-Musk Treasury Payments Crisis of 2025: Not “Read Only” access anymore, Notes on the Crises. Available at: https://www.crisesnotes.com/day-five-of-the-trump-musk-treasury-payments-crisis-of-2025-not-read-only-access-anymore/ (Accessed: 6 February 2025).

Tankus, N. (2025c) Day Seven of the Trump-Musk Treasury Payments Crisis of 2025: “Yours and WIRED’s Reporting is Actually Doing Something”, Notes on the Crises. Available at: https://www.crisesnotes.com/day-seven-of-the-trump-musk-treasury-payments-crisis-of-2025-yours-and-wireds-reporting-is-actually-doing-something/ (Accessed: 6 February 2025).

Appendix 1: A Draft of a "Federal Technical Reserve Act" (USA)

This section was created using the Federal Reserve Act as a starting point and iterating on the legislation. The aim was to safeguard the independence of a proposed Federal Technical Reserve by ensuring it had dual funding through appropriation from Congress together with levies from different Federal agencies:

Annual budget target: ~$150 million
Permanent appropriation: 0.3% of the total operating expenses of all designated critical systems for each fiscal year): (~$100-120 million)
Assessment portion needed: 0.15% of each agency's critical IT budget (~$30-50 million).

The core functioning of the agency should therefore be preserved, should a future president which to affect or control its operation. Extra oversight is given through an Inspector General, Congressional and Judicial review.

The risk assessment strategy was modelled on the EU AI Act risk classification and the cooling off period for significant changes to source code was to prevent DOGE style uncontrolled and chaotic system changes.

Tier I (Unacceptable Risk): Modifications that could enable, for example, Unilateral redirection, freezing, or manipulation of funds contrary to congressional authorization, as evidenced by the modification's capacity to move, restrict, or alter funds without required multi-party approvals. Or bypass of legally mandated processes for the allocation of public funds, including circumvention of appropriations controls, spending limits, or oversight mechanisms
Tier II (High Risk): Modifications that, for example, substantially alter system operations, security protocols, or functional parameters or change core data processing logic.
Tier III (Moderate Risk): Modifications of significant but limited scope that do not fundamentally alter system operations.
Tier IV (Minimal Risk): Routine maintenance, security updates, and minor modifications.

This is offered as a suggestive idea of how democratic systems might protect core governmental functions and a vision of a potential model for implementation. I welcome comments and criticisms – and I hope it can inspire other attempts to draft (and perhaps implement) legislation in different polities.

Proposed Federal Technical Reserve Act

An Act to provide for the establishment of the Federal Technical Reserve System, to establish a framework for the protection of critical computational infrastructure, to provide safeguards against authoritarian repurposing of government systems, and for other purposes.

Section 1. Short Title and Definitions

(a) SHORT TITLE

This Act may be cited as the "Federal Technical Reserve Act."

(b) DEFINITIONS

For purposes of this Act:

1. The term "Technical Reserve" means the Federal Technical Reserve System established by this Act.

2. The term "Board" means the Board of Governors of the Federal Technical Reserve System.

3. The term "critical computational infrastructure" means designated computer systems, networks, and software that process, manage, or control essential governmental functions or federal funds.

4. The term "modification" means any change to source code, configuration, operational parameters, or security controls of a designated system.

5. The term "Technical Division" means a specialized division of the Federal Technical Reserve System established under this Act.

6. The term "Division Director" means the head of a Technical Division appointed by the Board.

7. The term "agency" means an executive department, military department, Government corporation, Government controlled corporation, or other establishment in the executive branch of the Government, or any independent regulatory agency.

Section 2. Establishment and Purpose

(a) FEDERAL TECHNICAL RESERVE SYSTEM

There is established a Federal Technical Reserve System (hereinafter "the Technical Reserve") to safeguard the integrity, security, and constitutional operation of designated critical computational infrastructure.

(b) DUAL MANDATE

The Technical Reserve shall operate with a dual mandate of:

1. Ensuring the continuous, secure, and efficient operation of designated critical computational systems; and

2. Protecting such systems from unauthorized repurposing that could enable unconstitutional exercise of power.

The Technical Reserve shall be an independent agency within the executive branch of the Government of the United States.

Section 3. Board of Governors

(a) COMPOSITION

The Technical Reserve shall be governed by a Board of Governors consisting of seven members appointed by the President, by and with the advice and consent of the Senate.

(b) TERMS AND QUALIFICATIONS

1. Members shall serve for terms of fourteen years beginning on February 1 of even-numbered years and ending on January 31 of even-numbered years fourteen years later, with terms staggered so that one term expires on January 31 of each even-numbered year.

2. Members shall be chosen from among persons of demonstrated technical expertise, experience in governance of complex systems, and commitment to constitutional principles. At least four members must have significant experience in information technology, computer science, or cybersecurity.

3. In selecting members, the President shall have due regard to fair representation of technical backgrounds, professional experience, and demographic diversity.

4. No more than four members shall be affiliated with or recently affiliated with the same political party.

1. Members may only be removed by the President for cause, with such cause explicitly stated in writing and submitted to Congress.

2. "Cause" shall be limited to: neglect of duty, malfeasance in office, or conviction of a serious crime.

3. Any removal for cause shall be subject to judicial review.

(d) CHAIR AND VICE CHAIR

1. The President shall designate, by and with the advice and consent of the Senate, a Chair and Vice Chair from among the members of the Board, to serve for terms of four years.

2. The Chair shall preside at all meetings of the Board and shall be the active executive officer of the Board.

3. The Vice Chair shall serve in the absence or disability of the Chair, or in the event of a vacancy in the position of Chair.

(e) VACANCIES

1. Any vacancy on the Board shall be filled in the manner in which the original appointment was made.

2. A person appointed to fill a vacancy before the expiration of a term shall serve for the remainder of that term.

3. A member who has served a full fourteen-year term shall not be eligible for reappointment. A member who has served less than a full term may be reappointed for a full term.

4. In the event a successor is not appointed and qualified by the expiration of a member's term, the member may continue to serve until a successor has been appointed and qualified, but not to exceed a period of one year after the term expires.

(f) MEETINGS AND RECORDS

1. The Board shall meet at least quarterly and additionally as the Chair deems necessary or upon the written request of at least three members.

2. The Board shall keep a complete record of all its actions and deliberations and shall publish such records to the extent consistent with national security.

3. A majority of the Board shall constitute a quorum for the transaction of business.

Section 4. Powers of the Board

(a) GENERAL POWERS

The Board shall have the power to:

1. Establish and enforce technical standards for critical computational infrastructure

2. Review and approve or reject modifications to designated systems

3. Conduct examinations and audits of designated systems

4. Issue binding directives regarding system security and integrity

5. Establish policies to be implemented by Technical Divisions

6. Promulgate rules and regulations necessary to carry out the provisions of this Act

(b) REGULATIONS AND ORDERS

1. The Board is authorized to prescribe such regulations and to issue such orders as may be necessary to enable it to perform its duties and functions under this Act.

2. All regulations and orders shall be published in the Federal Register with appropriate redactions for national security.

3. Before issuing any regulation of general applicability, the Board shall provide for public notice and comment, except when the Board determines that urgent circumstances make such procedures impracticable.

The Board shall make an annual report to Congress, not later than April 1 of each year, concerning its operations and the state of critical computational infrastructure.

Section 5. Technical Divisions

(a) ESTABLISHMENT

1. The Board of Governors shall establish specialized Technical Divisions organized by system type and technical domain rather than geographic region.

2. Initial divisions shall include, at minimum:

* Payment and Financial Systems Division

* Records and Identity Systems Division

* Security and Access Control Systems Division

* Regulatory and Compliance Systems Division

* Core Infrastructure Systems Division

(b) DIVISION DIRECTORS

1. Each Technical Division shall be headed by a Director appointed by the Board for a six-year term.

2. Directors shall be selected based on demonstrated expertise in the relevant technical domain.

3. The Board shall establish an Advisory Committee for each Division consisting of:

* Three members appointed by the Board to represent the public interest

* Three members representing agencies operating designated critical infrastructure within the Division's domain

* Three technical experts nominated by professional associations and academic institutions

1. Technical Divisions shall:

* Conduct technical audits and assessments of systems within their domain

* Review and classify proposed modifications to designated systems

* Maintain technical documentation and code repositories

* Develop specialized expertise in relevant systems

* Implement policies established by the Board

* Provide technical guidance to agencies regarding best practices

* Report quarterly to the Board on the state of systems within their domain

Section 6. Designation of Critical Computational Infrastructure

(a) DESIGNATION PROCESS

1. The Secretary of the Treasury, the Secretary of Defense, and the Secretary of Homeland Security shall jointly submit to the Board of Governors a list of computational systems that they determine to be critical to:

* The processing, management, or control of federal funds

* The implementation of core governmental functions

* The maintenance of records essential to constitutional rights

* The security of the United States

2. The Board shall review this list and may modify it based on established criteria.

3. The final list shall be published and updated annually, with appropriate redactions for national security.

(b) INITIAL DESIGNATIONS

1. The following systems are designated as critical computational infrastructure upon enactment:

* Treasury payment processing systems, including but not limited to the Payment Automation Manager and Secure Payment System

* Federal benefits distribution systems

* Tax processing systems

* Federal payroll systems

* Federal procurement systems

* Electoral systems maintained by federal agencies

* Systems controlling access to classified information

* Federal identity and access management systems

* Emergency response coordination systems

1. The Board shall review the list of designated critical computational infrastructure at least annually and update as necessary.

2. Any agency may petition the Board to add, modify, or remove a system from designation.

Section 7. Risk Classification System

(a) ESTABLISHMENT

The Board shall establish a four-tier risk classification system for modifications to designated critical systems:

1. Tier I (Unacceptable Risk): Modifications that could enable:

* Unilateral redirection, freezing, or manipulation of funds contrary to congressional authorization, as evidenced by the modification's capacity to move, restrict, or alter funds without required multi-party approvals

* Bypass of legally mandated processes for the allocation of public funds, including circumvention of appropriations controls, spending limits, or oversight mechanisms

* Creation of backdoor access mechanisms that circumvent established security protocols, including any authentication, authorization, or audit capabilities that operate outside documented system controls

* Implementation of capabilities for targeting specific groups, entities, or political opponents, defined as functionality that enables differential treatment of individuals or organizations based on characteristics unrelated to legitimate system functions

2. Tier II (High Risk): Modifications that:

* Substantially alter system operations, security protocols, or functional parameters

* Change core data processing logic

* Modify access control mechanisms

* Introduce new automated decision capabilities affecting substantial rights or interests

3. Tier III (Moderate Risk): Modifications of significant but limited scope that do not fundamentally alter system operations.

4. Tier IV (Minimal Risk): Routine maintenance, security updates, and minor modifications.

(b) CLASSIFICATION PROCEDURES

1. Initial classification shall be determined by the responsible agency according to guidelines established by the Board.

2. Technical Divisions shall review classifications for systems within their domains.

3. The Board may elevate classifications based on its assessment.

4. Classification determinations shall be documented with written justification.

Section 8. Time Constraints and Procedures

(a) TIER I MODIFICATIONS (UNACCEPTABLE RISK)

1. Modifications classified as Tier I are prohibited except in cases of certified national emergency directly threatening national security.

2. Implementation of Tier I modifications requires:

* Certification by the Secretary of Defense or Homeland Security of immediate necessity

* Majority approval by the Board of Governors

* Notification to Congressional leadership

* Implementation of automatic sunset provisions not exceeding 60 days

* Creation of a restoration plan to remove the modification

(b) TIER II MODIFICATIONS (HIGH RISK)

1. Modifications classified as Tier II require:

* Submission to the relevant Technical Division and the Board at least 60 days before proposed implementation

* Technical review and approval by the Division

* Public notice through the Federal Register with appropriate security redactions

* A 45-day review period during which specified parties may challenge the classification or modification

* Board approval following the review period

1. Modifications classified as Tier III require:

* Notification to the relevant Technical Division at least 15 days before implementation

* Technical review and approval by the Division

* Documentation of the modification in the system's change log

(d) TIER IV MODIFICATIONS (MINIMAL RISK)

1. Modifications classified as Tier IV may proceed according to standard agency procedures, with:

* Documentation in the system's change log

* Compliance with technical standards established by the Board

* Post-implementation notification to the relevant Technical Division

(e) EMERGENCY PROCEDURES

1. In cases of critical system failure or imminent cybersecurity threat, the Board may establish expedited procedures for approving necessary modifications.

2. Emergency approvals shall be subject to post-implementation review.

3. Even under emergency procedures, essential documentation as determined by Board guidelines shall be maintained during the modification process, with complete documentation to be completed within 72 hours of implementation.

4. The Board shall establish minimum documentation requirements for emergency modifications that balance expediency with the need for oversight and security.

Section 9. Challenge Procedures

(a) STANDING TO CHALLENGE

The following parties may challenge the classification or implementation of Tier I or Tier II modifications:

1. Any member of Congress

2. Any state governor or state attorney general

3. Any agency head

4. The Board

5. Any person demonstrating substantial harm from the modification

(b) CHALLENGE PROCESS

1. Challenges shall be submitted to the Board and the agency responsible for the system.

2. The Board shall review the challenge and issue a determination within 15 days, which may be extended by up to an additional 15 days for technically complex modifications upon written notice to all relevant parties.

3. During review, implementation of the challenged modification shall be stayed.

4. The Board shall publish its determination with a full explanation of its reasoning, including an assessment of technical factors considered.

1. Board determinations regarding Tier I and Tier II modifications may be appealed to the United States Court of Appeals for the District of Columbia Circuit.

2. The court shall expedite consideration of such appeals.

3. Review shall be limited to whether the Board followed required procedures and whether the classification is arbitrary, capricious, or contrary to law.

Section 10. Technical Documentation Requirements

(a) CODE REPOSITORIES

1. The Technical Reserve shall maintain secure read-only copies of designated critical system repositories of:

* Source code for designated critical systems

* Technical documentation

* System architecture diagrams

* Change logs and modification histories

2. Access to repositories shall be strictly controlled according to security protocols established by the Board.

3. The Board shall establish version control and integrity verification protocols for all material in repositories.

(b) CHANGE DOCUMENTATION

1. All modifications to designated systems shall be:

* Cryptographically signed by authorized personnel

* Permanently recorded in tamper-evident logs

* Documented with stated purpose and expected effects

* Tagged with risk classification and approving authority

* Subject to review and verification by Technical Divisions

1. The Board shall establish minimum documentation requirements for:

* System architecture

* Data flows

* Security controls

* Dependency mapping

* Configuration parameters

* Test procedures

Section 11. Technical Standards

(a) ESTABLISHMENT OF STANDARDS

1. The Board shall establish technical standards for:

* System documentation

* Change management

* Access controls

* Audit logging

* Security protocols

* Resilience requirements

* Encryption requirements

* Authentication mechanisms

* Backup and recovery procedures

(b) STANDARD DEVELOPMENT PROCESS

1. The Board shall consult with:

* The National Institute of Standards and Technology

* Industry experts

* Academic researchers

* Government stakeholders

2. Standards shall be reviewed and updated at least every two years.

3. The Board shall establish procedures for agencies to request variances from standards where necessary.

1. The Board shall establish a framework for assessing and ensuring compliance with established standards.

2. Technical Divisions shall conduct periodic compliance assessments of systems within their domains.

Section 12. Annual Certification and Reporting

(a) AGENCY CERTIFICATION

1. The head of each agency operating designated critical infrastructure shall annually certify compliance with this Act.

2. Certification shall include:

* Confirmation that all modifications followed required procedures

* Summary of modifications implemented during the previous year

* Assessment of system security and resilience

* Identification of potential vulnerabilities

* Plans for addressing identified vulnerabilities

* Attestation of conformity with technical standards

(b) SYSTEM REPORTING

1. The Board shall report to Congress semi-annually on:

* The state of critical computational infrastructure

* Significant modifications reviewed or implemented

* Challenges to classifications or modifications

* Recommendations for legislative action

* Emerging threats and vulnerabilities

* Progress in implementing technical standards

1. The Board shall maintain a public website providing:

* Non-sensitive information about the Technical Reserve's activities

* Public versions of standards and guidelines

* Annual reports and statistics

* Educational resources regarding technical governance

Section 13. Technical Staff

(a) BOARD STAFF

1. The Board may appoint and fix the compensation of such officers and employees as necessary to carry out its functions.

2. Staff shall be appointed without regard to political affiliation and solely on the basis of technical qualifications.

3. The Board shall establish compensation schedules sufficient to attract and retain personnel with necessary technical expertise.

(b) TECHNICAL DIVISION STAFF

1. Each Technical Division may appoint technical specialists, auditors, and support staff necessary to fulfill its domain-specific functions, subject to overall staffing policies established by the Board.

2. The Technical Reserve shall establish competitive compensation to attract necessary expertise.

3. The Board may establish fellowship programs to bring academic and industry experts into temporary government service.

4. The Board shall define clear separation of responsibilities between Board staff and Division staff to avoid duplication of roles.

1. The Technical Reserve shall establish continuing education requirements for technical staff.

2. The Board shall provide resources for staff to maintain current knowledge of relevant technologies and threats.

Section 14. Technical Expertise Preservation

(a) KNOWLEDGE RETENTION PROGRAM

1. The Technical Reserve shall establish a program to:

* Document institutional knowledge regarding legacy systems

* Create training programs for critical skills

* Establish succession planning for key technical positions

* Provide incentives for knowledge transfer

2. The Board shall establish protocols for preserving knowledge when key personnel depart.

3. The knowledge retention program shall include:

* A mentorship system pairing senior technical staff with junior colleagues

* Mandatory documentation of specialized procedures and system knowledge

* Financial bonuses for staff who effectively document and transfer critical knowledge

* Regular knowledge-sharing sessions across Technical Divisions

* Creation of a centralized knowledge repository with appropriate security controls

* Exit interviews and knowledge capture processes for departing staff

(b) TECHNICAL CONTINUITY PLANNING

1. Each agency operating designated critical infrastructure shall develop and maintain technical continuity plans to ensure operational knowledge is preserved.

2. Plans shall be reviewed annually by the relevant Technical Division.

3. The Board shall establish minimum requirements for technical continuity plans.

Section 15. Office of Inspector General

(a) ESTABLISHMENT

1. There is established within the Technical Reserve an Office of Inspector General.

2. The Office shall be headed by an Inspector General, who shall be appointed by the President, by and with the advice and consent of the Senate.

3. The Inspector General shall serve for a term of five years and may be reappointed for additional terms.

4. The Inspector General may be removed from office by the President only for cause and with written notification to Congress at least 30 days prior to removal.

(b) DUTIES AND RESPONSIBILITIES

1. The Inspector General shall:

* Conduct independent and objective audits, investigations, and inspections of the Technical Reserve's programs and operations

* Prevent and detect fraud, waste, and abuse in the Technical Reserve's activities

* Review proposed modifications to critical computational infrastructure classified as Tier I or Tier II for compliance with this Act

* Provide leadership and coordination in recommending policies to promote efficiency and effectiveness

* Keep the Board and Congress fully informed about problems and deficiencies and the necessity for corrective action

2. The Inspector General shall have direct access to all records, reports, audits, reviews, documents, and materials of the Technical Reserve.

3. The Inspector General shall submit semi-annual reports to Congress on the Office's activities and findings.

1. The Office of Inspector General shall maintain organizational independence from the Board and Technical Divisions.

2. The Inspector General shall have independent authority to hire staff, conduct investigations, and issue reports without prior approval from the Board.

3. The Inspector General's budget shall be separately identified within the Technical Reserve's budget and shall be adequate to ensure effective oversight.

(d) WHISTLEBLOWER COORDINATION

1. The Office of Inspector General shall establish a dedicated whistleblower intake system to receive disclosures regarding the Technical Reserve and critical computational infrastructure.

2. The Inspector General shall coordinate with the Office of Special Counsel on whistleblower matters.

Section 16. Whistleblower Protections

(a) PROTECTED DISCLOSURES

1. No officer or employee of an agency operating designated critical infrastructure may be discharged, demoted, or otherwise discriminated against for disclosing information regarding:

* Violations of this Act

* Improper risk classifications

* Unauthorized system modifications

* Attempts to bypass required procedures

* Security vulnerabilities in designated systems

* Attempts to undermine system integrity

(b) DISCLOSURE CHANNELS

1. Protected disclosures may be made to:

* The Board or a Technical Division

* Congressional committees of jurisdiction

* Inspectors General

* The Office of Special Counsel

2. The Board shall establish secure channels for receiving protected disclosures.

1. An employee who believes they have been subject to prohibited retaliation may file a complaint with the Office of Special Counsel.

2. Remedies may include reinstatement, back pay, and compensatory damages.

Section 17. Implementation Timeline

(a) ESTABLISHMENT OF THE BOARD

1. Initial Board members shall be appointed within 180 days of enactment.

2. Initial appointments shall be for staggered terms as follows:

* One member appointed for a term ending January 31, 2028

* One member appointed for a term ending January 31, 2030

* One member appointed for a term ending January 31, 2032

* One member appointed for a term ending January 31, 2034

* One member appointed for a term ending January 31, 2036

* One member appointed for a term ending January 31, 2038

* One member appointed for a term ending January 31, 2040

3. Following these initial appointments, all subsequent appointments shall be for full fourteen-year terms, except when filling an unexpired term.

(b) TECHNICAL DIVISIONS

1. Technical Divisions shall be established within one year of enactment.

2. Division domains shall be defined by the Board within 90 days of its first meeting.

3. Division Directors shall be appointed within 180 days of the Board's first meeting.

1. The Board shall establish the risk classification system within 180 days of its first meeting.

2. Agencies shall begin classifying modifications within 30 days of system establishment.

3. Full implementation of review procedures shall be completed within 18 months of enactment.

Section 18. Funding

(a) PERMANENT APPROPRIATION

1. There is established in the Treasury of the United States a separate fund to be known as the "Federal Technical Reserve Fund" (hereinafter "the Fund").

2. The Fund shall be permanently available to the Board for carrying out its duties and responsibilities without fiscal year limitation.

3. There is permanently appropriated to the Fund, out of any money in the Treasury not otherwise appropriated, an amount equal to 3/10 of 1 percent of the total operating expenses of all designated critical computational infrastructure for each fiscal year.

4. The permanent appropriation shall be automatically adjusted annually based on a formula determined by the Secretary of the Treasury in consultation with the Board.

5. The permanent appropriation shall be sufficient to maintain core operations of the Technical Reserve, including essential staffing, technical infrastructure, and oversight functions.

(b) ASSESSMENT AUTHORITY

1. The Board shall levy semi-annual assessments on agencies operating designated critical infrastructure to supplement the permanent appropriation and fund enhanced Technical Reserve operations.

2. Assessments shall be proportional to the scope and complexity of systems under review.

3. The total annual assessments collected from all agencies combined shall not exceed 1/10 of 1 percent of the total operating expenses of all designated critical computational infrastructure for each fiscal year.

4. No individual agency shall be assessed more than 15/100 of 1 percent of its annual information technology budget for designated critical systems.

5. The Board shall establish assessment formulas through a public rulemaking process.

6. Agency assessments shall primarily fund:

* Expanded technical reviews and audits

* Advanced security research

* Technology modernization initiatives

* Special investigations and assessments

* Enhanced technical capabilities

7. If an agency claims insufficient budget to meet its assessment obligation:

* The agency head must certify this insufficiency to the Board and to Congress

* The Board shall work with the agency to develop a payment plan or alternative arrangement

* The Office of Management and Budget shall include the full assessment amount in the agency's next budget request

* The Board may authorize temporary reduced payments with the difference to be made up in future fiscal years

1. The Board shall determine its budget independently of the annual appropriations process.

2. The budget shall be submitted to Congress for informational purposes only.

3. The Board shall submit an annual financial report to Congress detailing both expenditures from the Fund and assessments collected.

4. The Government Accountability Office shall conduct an annual audit of the Technical Reserve's finances.

(d) CONTINGENCY RESERVE

1. The Board shall maintain a contingency reserve sufficient to sustain core operations for a period of at least one year in the event of significant shortfalls in agency assessment payments.

2. The contingency reserve shall be funded through a combination of the permanent appropriation and a portion of assessment collections during normal operations.

3. The Board shall establish policies governing the use of contingency reserve funds.

Section 19. Construction with Other Laws

(a) INTERACTION WITH EXISTING AUTHORITIES

1. Nothing in this Act shall be construed to impair the authority of agencies to operate and maintain systems under their jurisdiction.

2. This Act establishes procedural requirements for system modifications but does not transfer operational control to the Technical Reserve.

3. In the event of conflict between this Act and another federal statute, this Act shall take precedence with respect to the protection of critical computational infrastructure unless the other statute explicitly references this Act.

(b) NATIONAL SECURITY SYSTEMS

1. The President may exempt certain national security systems from specific provisions of this Act through a written determination.

2. Such determinations shall be reviewed by the relevant congressional committees.

3. Exemptions shall be limited to the minimum necessary to protect national security interests.

1. Review procedures established under this Act shall be in addition to, and not in lieu of, any administrative procedures required under the Administrative Procedure Act.

2. The Board's procedures shall be designed to complement and enhance existing administrative requirements.

Section 20. Severability

If any provision of this Act, or the application thereof, is held invalid, the remainder of the Act and the application of such provision to other persons or circumstances shall not be affected thereby.

Section 21. Technical and Conforming Amendments

(a) AMENDMENTS TO RELATED LAWS

1. [Specific amendments to other laws would be included here]

Section 22. Effective Date

This Act shall take effect 90 days after the date of its enactment.

Appendix 2: A Draft for an "Office for Technical Responsibility Act"(UK)

This proposal for an Office for Technical Responsibility Act establishes a British version of the Federal Technical Reserve as a safeguard for our critical computational infrastructure. This version was modelled on the British Office for Budget Responsibility and its creation via the Budget Responsibility and National Audit Act 2011.

At its core, the proposed Act below creates an independent body led by technical experts who will oversee and protect these systems from unauthorised repurposing that could enable unconstitutional exercises of power. The Technical Responsibility Committee, appointed with parliamentary approval, would establish technical standards, review high-risk modifications, and implement a comprehensive risk classification system that prohibits changes that could enable manipulation of funds, bypass legal processes, create backdoor access, or target specific groups. This represents a significant advancement in computational governance for the UK, acknowledging that democratic oversight of digital systems is essential for protecting our political order.

The legislation attempts to carefully balance technical expertise with democratic accountability through a multi-layered governance structure. An Oversight Board monitors the OTR's operations, while a Technical Appeals Panel allows for independent review of contested decisions before judicial review. The Act respects devolved administrations while ensuring coordination where systems interface, and addresses international considerations for systems connecting with EU or allied nations. With robust whistleblower protections, transparent reporting requirements, and measured implementation timelines, the Act creates a thoughtful framework for technological governance that protects both security and democratic values.

There is an important question to be asked about devolved responsibility as it would be important to build technical capacity in each of the devolved nations. It should be noted also that Information technology infrastructure and cybersecurity are not explicitly reserved matters under the Scotland Act 1998, Wales Act 2017, or Northern Ireland Act 1998. However, national security (which includes some aspects of cybersecurity) is reserved. As written below, the OTR applies mandatory provisions only to systems operated by UK Government departments and those supporting reserved functions, while creating a voluntary opt-in mechanism for systems operated by devolved administrations. This approach aims to respect devolved competencies in digital governance while ensuring coordination where systems interface with UK Government infrastructure. Nevertheless, the legislation would benefit from greater clarity on which provisions are mandatory versus voluntary to avoid constitutional issues. As computational systems increasingly underpin governance across all levels of government, this balanced approach acknowledges that effective technical governance must operate within established constitutional frameworks rather than overriding them.

Proposed Office for Technical Responsibility Act

An Act to establish the Office for Technical Responsibility; to make provision about the governance and functions of the Office for Technical Responsibility; to make provision about the protection of critical computational infrastructure; to provide safeguards against authoritarian repurposing of government systems; and for connected purposes.

Part 1 - The Office for Technical Responsibility

Constitution

1. Establishment of the Office for Technical Responsibility (1) There shall be a body corporate known as the Office for Technical Responsibility. (2) The Office for Technical Responsibility shall have the functions conferred on it by this Act. (3) The Office for Technical Responsibility shall be the central authority for the protection and oversight of designated critical computational infrastructure.

2. The Office for Technical Responsibility's objectives (1) In discharging its functions, the Office for Technical Responsibility shall have the following objectives— (a) to ensure the continuous, secure, and efficient operation of designated critical computational systems; and (b) to protect such systems from unauthorised repurposing that could enable the unconstitutional exercise of power. (2) The objectives in subsection (1) shall be known as the Office for Technical Responsibility's dual mandate.

3. Independence from political direction (1) The Office for Technical Responsibility shall be independent in relation to operational matters regarding the protection of critical computational infrastructure. (2) Ministers in the Cabinet Office shall not be entitled to give directions to the Office for Technical Responsibility with respect to the manner in which it protects critical computational infrastructure. (3) Ministers of the Crown shall not seek to influence the decisions of the Office for Technical Responsibility or its committee members in carrying out their functions.

4. Relationship with Parliament (1) The Office for Technical Responsibility shall be accountable to Parliament for the discharge of its responsibilities under this Act. (2) The Technical Responsibility Committee shall, on Parliamentary request, cause a member of the Committee to appear before a Parliamentary committee to answer questions regarding the Office for Technical Responsibility's functions.

Governance and membership

5. Technical Responsibility Committee (1) There shall be a Technical Responsibility Committee of the Office for Technical Responsibility. (2) The Technical Responsibility Committee shall consist of— (a) a Chair, appointed by the Minister for the Cabinet Office with the approval of the relevant Parliamentary committee; (b) at least two but not more than four other members, appointed by the Minister for the Cabinet Office after consultation with the Chair; and (c) the Chief Executive of the Office for Technical Responsibility. (3) The Chair and other members of the Technical Responsibility Committee shall be appointed for terms of five years. (4) The Technical Responsibility Committee shall be responsible for— (a) the strategic direction of the Office for Technical Responsibility; (b) reviewing and approving modifications to designated systems; (c) establishing and enforcing technical standards; (d) monitoring the identification and mitigation of systemic risks; and (e) fulfilling the Office for Technical Responsibility's statutory responsibilities. (5) A quorum of the Technical Responsibility Committee shall be three members, including either the Chair or, in the Chair's absence, a member designated by the Chair to act in that capacity. (6) Decisions of the Technical Responsibility Committee shall be made by a majority vote of members present, with the Chair having a casting vote in the event of a tie.

6. Qualification for appointment (1) Members of the Technical Responsibility Committee shall be chosen from among persons with demonstrated technical expertise, experience in governance of complex systems, and commitment to constitutional principles. (2) At least two members must have significant experience in information technology, computer science, or cybersecurity. (3) In selecting members, the Minister for the Cabinet Office shall have due regard to fair representation of technical backgrounds, professional experience, and demographic diversity.

7. Terms of office and removal (1) A person appointed as Chair or member of the Technical Responsibility Committee shall work such hours as are necessary for the proper discharge of the functions assigned to them. (2) A member may be removed from office only on the grounds of incapacity or serious misconduct, with such grounds explicitly stated in writing and laid before Parliament. (3) A member who has served a full five-year term shall be eligible for reappointment for one additional term.

8. Chief Executive (1) There shall be a Chief Executive of the Office for Technical Responsibility, who shall be appointed by the Minister for the Cabinet Office with the agreement of the Chair of the Technical Responsibility Committee. (2) The Chief Executive shall be responsible for— (a) the day-to-day management of the Office for Technical Responsibility; (b) ensuring the Office for Technical Responsibility carries out its statutory functions; (c) allocation of resources within the Office for Technical Responsibility; and (d) staffing of the Office for Technical Responsibility. (3) The Chief Executive shall serve for a term of five years and may be reappointed. (4) The Chief Executive shall be a member of the Technical Responsibility Committee but may not serve as its Chair.

Powers and duties

9. Powers of the Office for Technical Responsibility (1) The Office for Technical Responsibility, acting through the Technical Responsibility Committee, shall have the power to— (a) establish and enforce technical standards for critical computational infrastructure; (b) review and approve or reject significant modifications to designated systems; (c) conduct examinations and audits of designated systems; (d) issue binding directives regarding system security and integrity; (e) make such regulations as appear to it necessary and expedient for the purpose of enabling it to carry out its functions under this Act. (2) A Minister in the Cabinet Office may by order specify matters that the Office for Technical Responsibility must take into account in connection with the discharge of its functions under this Act.

10. Publications by the Office for Technical Responsibility (1) The Office for Technical Responsibility shall publish all regulations and directives with appropriate redactions for national security. (2) Before issuing any regulation of general applicability, the Office for Technical Responsibility shall conduct a consultation, except when the Office for Technical Responsibility determines that urgent circumstances make such procedures impracticable. (3) The Office for Technical Responsibility shall maintain a public website providing— (a) non-sensitive information about the Office for Technical Responsibility's activities; (b) public versions of standards and guidelines; (c) annual reports and statistics; (d) educational resources regarding technical governance.

11. Annual report (1) The Office for Technical Responsibility shall make an annual report to Parliament, not later than 30 June of each year, concerning its operations and the state of critical computational infrastructure. (2) The annual report shall contain— (a) a report by the Chair on the activities of the Office for Technical Responsibility in the previous financial year; (b) a statement of the Office for Technical Responsibility's accounts for the previous financial year; (c) a report on the state of critical computational infrastructure; (d) a summary of significant modifications reviewed or implemented; (e) recommendations for legislative action; and (f) a report on emerging threats and vulnerabilities.

Part 2 - Critical Computational Infrastructure

12. Designation of critical computational infrastructure (1) The Minister for the Cabinet Office, the Secretary of State for Defence, and the Secretary of State for the Home Department shall jointly submit to the Technical Responsibility Committee a list of computational systems that they determine to be critical to— (a) the processing, management, or control of public funds; (b) the implementation of core governmental functions; (c) the maintenance of records essential to constitutional rights; or (d) the security of the United Kingdom. (2) The Technical Responsibility Committee shall review this list and may modify it based on established criteria. (3) The final list shall be published and updated annually, with appropriate redactions for national security.

13. Initial designations (1) The following systems are designated as critical computational infrastructure upon commencement of this Act— (a) Treasury payment processing systems; (b) welfare benefits distribution systems; (c) tax processing systems; (d) public service payroll systems; (e) public procurement systems; (f) electoral systems maintained by public bodies; (g) systems controlling access to classified information; (h) public identity and access management systems; and (i) emergency response coordination systems.

14. Periodic review (1) The Technical Responsibility Committee shall review the list of designated critical computational infrastructure at least annually and update as necessary. (2) Any public body may petition the Technical Responsibility Committee to add, modify, or remove a system from designation.

Part 3 - System Modifications and Controls

15. Modification classification and procedures (1) The Technical Responsibility Committee shall establish a risk classification system for modifications to designated critical systems. (2) The classification system shall include: (a) Unacceptable-risk modifications that could enable: (i) unilateral redirection, freezing, or manipulation of funds contrary to parliamentary authorisation; (ii) bypass of legally mandated processes for the allocation of public funds; (iii) creation of backdoor access mechanisms that circumvent established security protocols; or (iv) implementation of capabilities for targeting specific groups, entities, or political opponents; (b) High-risk modifications that could fundamentally alter system operations or security; (c) Moderate-risk modifications of significant but limited scope; and (d) Low-risk modifications including routine maintenance and security updates. (3) The Technical Responsibility Committee shall establish proportionate review and approval processes for each risk level. (4) Unacceptable-risk modifications are prohibited except in cases of certified national emergency directly threatening national security, and require: (a) certification by the Secretary of State for Defence or the Home Secretary of immediate necessity; (b) majority approval by the Technical Responsibility Committee; (c) notification to the Prime Minister and Cabinet; (d) implementation of automatic sunset provisions not exceeding 60 days; and (e) creation of a restoration plan to remove the modification. (5) High-risk modifications shall require: (a) submission to the Technical Responsibility Committee at least 30 days before proposed implementation; (b) technical review and approval by the Committee; (c) public notice with appropriate security redactions; and (d) a review period during which specified parties may challenge the modification. (6) Public bodies shall document all modifications in system change logs, regardless of risk level.

16. Emergency procedures (1) In cases of critical system failure or imminent cybersecurity threat, the Technical Responsibility Committee may establish expedited procedures for approving necessary modifications. (2) Emergency approvals shall be subject to post-implementation review. (3) Even under emergency procedures, essential documentation shall be maintained during the modification process.

17. Challenge procedures (1) The following parties may challenge the implementation of unacceptable-risk or high-risk modifications— (a) any Member of Parliament; (b) any Minister of the Crown; (c) any public body head; or (d) the Technical Responsibility Committee. (2) Challenges shall be submitted in writing to the Technical Responsibility Committee, specifying the grounds for the challenge. (3) The Technical Responsibility Committee shall review the challenge and issue a determination within 15 days. (4) During review, implementation of the challenged modification shall be stayed. (5) Any party dissatisfied with the determination of the Technical Responsibility Committee may appeal that determination to the Technical Appeals Panel within 10 days of receiving the determination.

18. Technical Appeals Panel (1) There shall be established a Technical Appeals Panel to review appeals of determinations made by the Technical Responsibility Committee regarding challenges to unacceptable-risk or high-risk modifications. (2) The Technical Appeals Panel shall consist of: (a) three technical experts appointed by the Oversight Board; and (b) two legal experts with experience in public administrative law. (3) The Panel shall review appeals within 20 days of filing and issue a determination. (4) During the appeal process, the Technical Responsibility Committee's determination shall remain in effect unless the Technical Appeals Panel orders otherwise. (5) The decision of the Technical Appeals Panel may be further appealed through judicial review, as provided in section 19.

19. Judicial review (1) Technical Responsibility Committee determinations regarding unacceptable-risk or high-risk modifications may be subject to judicial review. (2) The court shall expedite consideration of such reviews. (3) Review shall be limited to whether the Technical Responsibility Committee followed required procedures and whether the classification is unreasonable, irrational or contrary to law.

Part 4 - Technical Standards and Documentation

20. System documentation requirements (1) The Office for Technical Responsibility shall maintain secure copies of: (a) source code for designated critical systems; (b) technical documentation; (c) system architecture diagrams; and (d) change logs and modification histories. (2) All modifications to designated systems shall be: (a) cryptographically signed by authorised personnel; (b) permanently recorded in tamper-evident logs; (c) documented with stated purpose and expected effects; and (d) tagged with risk classification and approving authority. (3) All documentation maintained by the Office for Technical Responsibility shall be classified according to the Government Security Classifications Policy.

21. System monitoring (1) The Office for Technical Responsibility shall establish procedures for: (a) continuous monitoring of designated systems for unauthorized changes; (b) detection of security breaches or anomalous behavior; and (c) regular security assessments of critical computational infrastructure. (2) Public bodies shall cooperate with the Office for Technical Responsibility in implementing monitoring solutions.

22. Technical standards (1) The Technical Responsibility Committee shall establish technical standards for— (a) system documentation; (b) change management; (c) access controls; (d) audit logging; (e) security protocols; (f) resilience requirements; and (g) encryption requirements. (2) The Technical Responsibility Committee shall consult with the National Cyber Security Centre, the Government Digital Service, the Central Digital and Data Office, and other relevant stakeholders when developing standards. (3) Standards shall be reviewed and updated at least every two years.

23. Annual certification (1) The head of each public body operating designated critical infrastructure shall annually certify compliance with this Act. (2) Certification shall include— (a) confirmation that all modifications followed required procedures; (b) summary of modifications implemented during the previous year; (c) assessment of system security and resilience; and (d) identification of potential vulnerabilities.

Part 5 - Oversight and Accountability

24. Oversight Board (1) There shall be an Oversight Board of the Office for Technical Responsibility. (2) The Oversight Board shall consist of: (a) a Chair, who shall be a person with significant experience in governance of public bodies, appointed by the Minister for the Cabinet Office; and (b) at least two but not more than four other members, appointed by the Minister for the Cabinet Office. (3) The Oversight Board shall: (a) oversee the effective governance of the Office for Technical Responsibility; (b) provide assurance on risk management and internal control; (c) review the economy, efficiency and effectiveness with which the Office for Technical Responsibility uses its resources; (d) monitor the independence of the Office for Technical Responsibility; and (e) report annually to Parliament on the discharge of its functions. (4) The Oversight Board shall meet at least quarterly. (5) The Chair of the Technical Responsibility Committee shall attend meetings of the Oversight Board but shall not be a member of it.

Part 6 - Administration and Staff

25. Technical staff (1) The Technical Responsibility Committee may appoint such officers and employees as necessary to carry out its functions. (2) Staff shall be appointed without regard to political affiliation and solely on the basis of technical qualifications. (3) The Technical Responsibility Committee shall establish compensation schedules sufficient to attract and retain personnel with necessary technical expertise.

26. Technical expertise preservation (1) The Office for Technical Responsibility shall establish a programme to document institutional knowledge regarding critical systems. (2) Each public body operating designated critical infrastructure shall develop and maintain technical continuity plans to ensure operational knowledge is preserved.

Part 7 - Financial Provisions

27. Funding (1) The expenses of the Office for Technical Responsibility shall be paid out of money provided by Parliament. (2) The Cabinet Office shall ensure the Office for Technical Responsibility has adequate resources to perform its functions effectively. (3) The Office for Technical Responsibility shall submit an annual budget request to the Cabinet Office. (4) The Technical Responsibility Committee shall submit an annual financial report to Parliament detailing its expenditures. (5) The National Audit Office shall conduct an annual audit of the Office for Technical Responsibility's finances.

28. Financial Memorandum (1) There shall be published alongside this Act a Financial Memorandum setting out: (a) the estimated costs of establishing the Office for Technical Responsibility; (b) the estimated annual operating costs of the Office for Technical Responsibility; and (c) the expected resource implications for public bodies subject to this Act. (2) The Financial Memorandum shall be updated annually for the first three years of operation.

Part 8 - Miscellaneous and General

29. Cooperation with other bodies (1) The Office for Technical Responsibility shall cooperate with: (a) the National Cyber Security Centre on matters related to cybersecurity; (b) the Information Commissioner's Office on matters related to data protection; (c) the Government Digital Service and Central Digital and Data Office on matters related to government digital infrastructure; (d) similar bodies in allied countries on matters of international significance; and (e) other relevant regulatory bodies.

30. Devolution (1) This Act applies to systems operated by UK Government departments and public bodies. (2) For systems operated by devolved administrations: (a) the Office for Technical Responsibility shall provide advice and guidance upon request; (b) devolved administrations may voluntarily subject their systems to the provisions of this Act through a memorandum of understanding; and (c) where systems interface with UK Government systems, technical standards shall be coordinated to ensure interoperability and security.

31. International aspects (1) For systems that interface with international partners or European Union systems: (a) the Office for Technical Responsibility shall coordinate with relevant international bodies to ensure compatibility of standards; (b) the Office for Technical Responsibility shall advise on technical implications of international agreements affecting critical computational infrastructure; and (c) where UK systems process data from international sources, appropriate safeguards and standards shall be implemented.

32. Implementation timeline (1) Initial Technical Responsibility Committee members shall be appointed within 180 days of commencement. (2) The Technical Responsibility Committee shall establish the risk classification system within 180 days of its first meeting. (3) Public bodies shall begin classifying modifications within 30 days of system establishment. (4) Full implementation of review procedures shall be completed within 12 months of commencement.

33. Transition provisions (1) Systems in existence at the time of commencement shall be subject to: (a) an initial cataloguing phase of 6 months; (b) a technical baseline assessment within 12 months; and (c) a phased implementation of compliance requirements not to exceed 24 months from commencement. (2) The Technical Responsibility Committee may grant extensions to specific compliance deadlines upon written application demonstrating reasonable need.

34. Relationship with other legislation (1) Nothing in this Act shall be construed to impair the authority of public bodies to operate and maintain systems under their jurisdiction. (2) This Act establishes procedural requirements for system modifications but does not transfer operational control to the Office for Technical Responsibility. (3) Whistleblower protections under the Public Interest Disclosure Act 1998 shall apply to disclosures regarding critical computational infrastructure.

35. National security systems (1) His Majesty may by Order in Council, on the advice of the Secretary of State for Defence or the Home Secretary, exempt certain national security systems from specific provisions of this Act. (2) Such exemptions shall be reviewed by the relevant Parliamentary committees.

36. Regulations (1) The Office for Technical Responsibility may make such regulations as appear to it necessary and expedient for the purpose of enabling it to carry out its functions under this Act. (2) A statutory instrument containing regulations under this Act shall be subject to: (a) the negative resolution procedure for regulations concerning technical standards and operational matters; and (b) the affirmative resolution procedure for regulations concerning matters of significant public interest, including those affecting rights of public bodies or individuals.

37. Interpretation (1) In this Act— "Technical Responsibility Committee" means the governing committee of the Office for Technical Responsibility established under section 5; "critical computational infrastructure" means designated computer systems, networks, and software that process, manage, or control essential governmental functions or public funds; "modification" means any change to source code, configuration, operational parameters, or security controls of a designated system; "unacceptable-risk modification" means a modification falling within any of the categories specified in section 15(2)(a) of this Act; "high-risk modification" means a modification falling within the category specified in section 15(2)(b) of this Act; "moderate-risk modification" means a modification falling within the category specified in section 15(2)(c) of this Act; "low-risk modification" means a modification falling within the category specified in section 15(2)(d) of this Act; "public body" means a body or organisation in the public sector, including government departments, executive agencies, non-departmental public bodies, local authorities, NHS bodies, and public corporations; "Office for Technical Responsibility" means the body corporate established under section 1; "Minister in the Cabinet Office" means a Minister of the Crown in the Cabinet Office; "Minister for the Cabinet Office" means the Minister of the Crown who is designated as such by the Prime Minister; "Technical Appeals Panel" means the panel established under section 18 of this Act.

38. Extent, commencement and short title (1) This Act extends to the whole of the United Kingdom. (2) This Act shall come into force on such day as a Minister in the Cabinet Office may by order appoint, and different days may be appointed for different provisions. (3) This Act may be cited as the Office for Technical Responsibility Act.