Auditing a post-quantum programme: what internal audit should test
How internal audit can give independent assurance over a post-quantum programme: who does what, when to audit, what to test and how to report.
What you’ll learn
- Explain the different roles of management and internal audit in a post-quantum programme.
- Describe what to test at each stage, from design to retiring the old algorithms.
- Explain why "migrated" should mean the quantum risk is mitigated, not just that post-quantum support was added.
Recommended background: Post-quantum cryptography for non-engineers, Two quantum programmes
On this page
Sooner or later the audit committee asks internal audit a fair question: is the bank's post-quantum programme real, and is it on track? This piece is for the auditors who have to answer it, and for the programme and risk teams who will be audited. It sets out who does what, when internal audit should get involved, what to test in each part of a programme, and how to stay independent of work that isn't internal audit's to do. It follows the structure of the banking guide, so each area links to the chapter that describes what good looks like.
Who does what
The Institute of Internal Auditors' Three Lines Model is the usual starting point. The IIA restated it in a 2026 Statement of Position, which replaces its earlier paper and keeps the model's core structure. The board sets direction and risk appetite and oversees the organisation. First-line roles own the risk day to day and design, implement and operate the processes and controls. Second-line roles, such as risk and compliance, provide specialist expertise, monitoring and challenge; they support management but are not independent of it. Internal audit, the third line, gives independent, objective assurance and advice, with a functional reporting line to the board. OSFI's corporate governance guidance similarly expects oversight functions, including internal audit, to stay independent of operational management.
In a post-quantum programme, that translates simply. The programme team and technology owners build the inventory, rank what to fix, change systems and manage suppliers. Second-line risk and compliance turn the board's risk appetite into limits and indicators, monitor progress and challenge the plan. Internal audit tests whether all of that is designed well and working, and tells the audit committee what it found. The board and its audit committee oversee the whole programme and receive regular reporting from management, as well as internal audit's independent view.
Keeping independence
Post-quantum work is new, and the people who understand it are scarce, so there's a pull to ask internal audit to help build things. The IIA's model is clear that internal audit gives advice without assuming management responsibility or decision-making authority, and that independence also depends on structure: a functional reporting line to the board, control over its own scope and unrestricted access. In practice:
- Internal audit doesn't build or own the programme's artefacts. It doesn't write the inventory template, choose scanning tools, set algorithm standards, score systems or approve migrations.
- Early advice is allowed, with care. An advisory review of the programme's design, before much is built, can be valuable, as long as management makes the decisions. Internal audit shouldn't later give assurance over work it designed or ran without addressing that conflict, for example by using people who weren't involved or a qualified third party.
- If internal audit takes on second-line work, safeguards are required. The IIA's 2026 statement calls this a direct self-review threat, and sets out safeguards: a documented justification, full disclosure to the board, and independent assurance over that area for as long as the overlap lasts.
- Specialist help is a skills question, not a role change. If the audit team lacks cryptography expertise, it can bring in a specialist to support its testing. The specialist works for the audit, not the programme.
When to audit
A post-quantum programme runs for years, so one audit at the end is too late and an audit of everything at the start is too early. A staged approach fits better:
- Design stage. An advisory or assurance review of governance: ownership, risk register entry, scope, reporting and funding. This is where weaknesses are cheapest to fix.
- Discovery stage. Assurance over the inventory and prioritisation, once there's enough of each to sample.
- Migration stage. Assurance over change control, testing, supplier delivery and whether reported progress matches what's actually been migrated.
- Retirement stage. Assurance that quantum-vulnerable algorithms have actually been disabled, isolated or tunnelled, not just supplemented with a post-quantum option.
What to test, area by area
The table is a starting point for an audit programme, not a complete one. Each area links to the guide chapter that sets out the practice being tested.
| Area | What to ask for | Example tests | Warning signs |
|---|---|---|---|
| Governance | Named accountable executive, risk register entry, steering committee papers and minutes, funding decisions | Trace a sample of reported measures back to their underlying evidence; check the risk rating's rationale is documented and reviewed | No named owner; a single "readiness percentage"; quantum pilots reported as if they were migration progress |
| Inventory | Scope document, inventory records with how each item was found and how confident the team is in it | Walk a sample of critical business flows end to end and check each use of cryptography is recorded; reconcile against certificate and key-management records | Inventory built only from scans; most records inferred rather than documented; no owner for gaps |
| Prioritisation | Scoring method, scored list, the data-retention periods used | Re-perform the scoring for a sample; check retention periods against the bank's records retention schedule | Scores with no documented inputs; data lifetimes that contradict retention policy |
| Crypto-agility | Cryptographic standards, exceptions register, certificate automation data | Check a sample of new or changed systems against the standard; test that exceptions are approved and time-limited | New systems hard-coding today's algorithms; exceptions with no expiry |
| Suppliers | Supplier tiering, questionnaires and responses, contract terms | For a sample of critical suppliers, check a response was received and assessed; check new contracts include the agreed post-quantum terms | Questionnaires sent but never assessed; renewals signed without post-quantum terms |
| Roadmap and re-planning | Milestones with completion criteria, the trigger log, re-plan decisions | Check milestones are testable; check that triggers that fired were assessed and the decision recorded | Milestones described as activities rather than outcomes; no record of reviewing new developments |
The quality of the evidence
Post-quantum programmes generate a lot of self-reported information, so judging evidence matters more than usual. A few distinctions help:
- How was it found? An automated scan, a code or configuration review, and a supplier's written statement are different kinds of evidence, and an inventory should record which applies to each item.
- Documented or inferred? "We believe this system uses RSA-2048" is not the same as a configuration export showing it. A high share of inferred records isn't a failure early on, but the trend should improve.
- Migrated or merely supported? Adding post-quantum support doesn't complete a migration if connections or operations that use only the old algorithms are still allowed. A properly designed hybrid, which combines a post-quantum algorithm with a traditional one, is built to stay secure as long as either component holds, so keeping the traditional half can be acceptable when the hybrid is enforced. Some legacy systems may instead be isolated, or have their traffic tunnelled inside a post-quantum-protected layer. Canada's federal roadmap, for example, treats a migration as complete when vulnerable algorithms are disabled, isolated or tunnelled, so that the quantum risk is mitigated rather than post-quantum cryptography merely supported. Ask what "done" means in the bank's own milestone definitions, and test it, rather than relying on a product's claim of post-quantum support.
Reporting to the audit committee
Findings are most useful when they say what the committee can rely on. Is management's reported progress supported by evidence? Are the most exposed systems and data actually first in line? Is the bank learning about new developments and reacting in a controlled way? Avoid framing post-quantum readiness as a pass or fail against an external deadline. As Post-quantum in Canada explains, there's no OSFI post-quantum deadline. What OSFI's Guideline B-13 does require, today, is sound management of technology and cyber risk, and cryptography is part of that.
What you’ve learned
- Management builds and runs the programme; internal audit gives independent assurance and owns none of it.
- Audit in stages: design, discovery, migration and retirement each need different tests.
- Test the evidence behind reported progress, and check that "migrated" means the quantum risk has been mitigated, not just that post-quantum support was added.
Check your understanding optional
A system now supports post-quantum algorithms. Can audit treat it as migrated?
Show the answer
Not yet. Audit should check that the quantum risk is actually mitigated, for example that the vulnerable algorithm is no longer accepted or that a properly enforced hybrid is in use, not only that post-quantum support was added.
Written by Muhammad Atif · Reviewed 17 October 2026 · How sources are chosen and checked · Report a correction
Sources and further reading
Tags show what kind of source each one is. A standard or government guidance is an official document; a peer-reviewed paper has been checked by other experts; a preprint has not been peer-reviewed yet; an experiment reports a real-world demonstration; a company announcement is the company's own account; vendor documentation is a supplier's own technical guide; expert commentary is a specialist's published analysis or opinion; a news report is a journalist's account. Dates and figures were checked against these sources on 17 October 2026. Spotted an error? Email hello@plainquantum.com and it will be corrected, with a note.
- Industry guidanceAssurance and Advice in Support of Effective Governance: Three Lines Model, Statement of PositionThe Institute of Internal Auditors, 2026
- Industry guidanceThe IIA's Three Lines Model: an update of the Three Lines of Defense (2020; replaced by the 2026 Statement of Position)The Institute of Internal Auditors, 2020
- StandardGlobal Internal Audit Standards (effective 9 January 2025)The Institute of Internal Auditors, 2024
- Government guidanceFinal Corporate Governance Guideline: letter (oversight functions, including internal audit, independent of operational management)Office of the Superintendent of Financial Institutions (OSFI), 2018
- Government guidanceGuideline B-13: Technology and Cyber Risk ManagementOffice of the Superintendent of Financial Institutions (OSFI), 2022
- Government guidanceTechnology Risk Bulletin ("These bulletins are not regulatory expectations")Office of the Superintendent of Financial Institutions (OSFI), 2026
- Government guidanceTechnology Risk Bulletin: Quantum Readiness Phases and TimelinesOffice of the Superintendent of Financial Institutions (OSFI), 2026
- Government guidanceGuideline B-10: Third-Party Risk ManagementOffice of the Superintendent of Financial Institutions (OSFI), 2023
- Government guidanceRoadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)Canadian Centre for Cyber Security, 2025
- Government guidanceMigrating the Government of Canada to post-quantum cryptography: Security Policy Implementation NoticeTreasury Board of Canada Secretariat, 2025
- Informational RFCRFC 9794: Terminology for Post-Quantum Traditional Hybrid SchemesInternet Engineering Task Force (IETF), 2025
- Government guidanceConsiderations for Achieving Cryptographic Agility (CSWP 39)NIST, 2025
- StandardCryptography Bill of Materials (CBOM)CycloneDX / OWASP