Scoping fourteen applications in twenty-five days

Arithmetic first. 25 auditor-days with two auditors is 25 person-days in total, not 50 - the days are the budget. A credible in-depth application audit covering ANF adequacy, ASC implementation, verification and validation takes roughly four days per application; 14 applications alone would consume 56 days, before ONF review, process review, supplier interfaces, reporting and follow-up. The sponsor's request is therefore impossible without either extending the budget or reducing depth, and the auditor's job is to say so in writing rather than silently under-audit.

Proposed scope. In scope: the ONF or its equivalent, the application security management process, the three ANFs, application-level implementation for a sample, and the two supplier interfaces. Out of scope: general IT infrastructure controls, although network, CI/CD and logging evidence is used as supporting evidence where an ASC depends on it.

Sampling.

• Document-level ANF-to-ASC traceability check for all 14 applications (approximately 5 days), which gives every application some coverage.
• Full audit of 5 applications: both claims applications handling special-category data (highest targeted trust level), one portal application (multi-tenancy is the largest blast radius), one internal tooling application as a contrast case to test whether low-risk applications are treated proportionately, and the application involved in the open ANF-update nonconformity.
• Half a day each with supplier A and supplier B on ASC evidence handover and change notification.
• Six days reserved for ONF and process review, reporting, and two days for follow-up on the open nonconformities.

What conclusions cover. Findings about the sampled applications are direct. For the other nine, conclusions are limited to whether ANF and ASC documentation exists and is traceable; state this limitation explicitly in the report, record the sampling rationale, and resist any wording in the executive summary that implies full coverage.

Criteria. The organisation's ONF and ANF procedures; the adopted requirements from 27034-2 (ONF content), 27034-3 (application security management process) and 27034-4 (verification and validation); the supplier contracts, which specify ASC evidence obligations; and the operator's health-data obligations, which set the trust level floor for tenant isolation.

Evidence plan - multi-tenant portal.

• ANF: approved trust level with rationale, ASC selection, tailoring justifications, change history since last audit.
• ASC implementation: code review of tenant-context handling; configuration of the data-access layer; CI/CD pipeline gates and their failure records.
• Verification: who tested tenant isolation, against what method, with what result, and whether the tester was independent of the author.
• Validation: evidence that isolation was exercised in a production-like environment, and any penetration test reports with remediation tracking.
• Operational: incident and near-miss records for cross-tenant exposure, monitoring rules, and log retention.
• Interviews with the product owner, a developer and an operations engineer, using the same questions to detect inconsistency.

Open nonconformities. For the ANF update failure, test the release-to-ANF-update trigger: pull three recent releases and check whether each produced an ANF review; determine whether the miss was isolated or the trigger does not exist. For the missing verification evidence, inspect the ASC's verification attribute to see whether a method was ever defined; if not, the defect is in the ASC, not the project.

Ranking of evidence. Re-performance and direct observation outrank inspection of records, which outranks interview. A signed record contradicted by observation is not sufficient. Every ASC conclusion should rest on at least one source that the auditee cannot self-produce.

Competence mapping. Required competences are: 27034-2 ONF structure and 27034-3 management process (both auditors hold this); ASC verification and validation assessment including secure code review (one auditor is strong, one is developing); cloud multi-tenancy and tenant-isolation architecture (a gap); health-data regulatory context (partial); supplier audit techniques (partial). The gap that matters most is multi-tenancy, because the portal family carries the largest potential impact and the most technically contestable evidence.

Use of the expert. The three expert days are allocated to: a half-day architecture walkthrough; one day reviewing the tenant-isolation test design and results alongside the auditor, so the reasoning transfers and is recorded; and one day on call for the full-audit portal application plus report review. The expert advises; the auditor concludes and signs. Record the expert's input in the workpapers so the basis of the technical judgement is traceable.

Managing the sponsor. Give the arithmetic, then offer explicit options: extend to 56 or more person-days for full depth; retain 25 days and accept a risk-based sample with stated limitations; or add auditors. Ask the sponsor to choose in writing. If the sponsor chooses reduced depth, record that as a scope limitation imposed by the auditee, and reflect it in the report's opinion. Do not accept an instruction that the report will 'cover all 14 applications' when only documentation was examined - that is a reporting integrity issue, not a client-preference issue.

Finally, brief the junior member on interview technique and review every set of notes before it enters the file.