The Vendor Checklist Exemption Request

Answer: refuse the exemption, but convert the vendor material into an input rather than a substitute.

Reasoning steps:

1. Separate the artefacts from the framework. The ONF is Northwind's own normative framework: it defines which ASCs exist, how they are selected for an application, how their implementation is verified and what evidence is retained. A SOC 2 report is an auditor's opinion about a supplier's control environment; an ASVS checklist is a requirements catalogue. Neither is a Northwind ASC set, and neither carries Northwind's evidence obligations.
2. Test the coverage claim by mapping, not by assertion. Spend two to three days mapping the vendor's SOC 2 control descriptions and the ASVS items to the 180 catalogued ASCs. The output is three buckets: ASCs genuinely satisfied by an inherited supplier control (record as inherited, with the report as evidence and the report's period and scope noted), ASCs partially addressed (implement the gap), and ASCs with no coverage. This preserves traceability while avoiding duplicated effort, and it takes far less time than a full build from scratch.
3. Explain the failure mode. An exemption produces an application with no documented ASC set, no comparable verification basis against the other 39 applications, and no defensible answer when the auditor asks how the control set was determined. It also transfers hidden risk to the application owner who never agreed to it.
4. Keep decision rights clean. The implementer owns the method; the accountable application owner owns any residual risk. If the business still wants to proceed with reduced scope, that is a written, time-bound risk acceptance above the implementer's level, not an exemption granted by the delivery manager.

Answer: the level is derived from business criticality and security attributes, not from network topology.

Argument to make:

• Decompose 'internal only'. The claim is false on its own facts. Sixty partner organisations and an offshore support team are third parties; they extend the threat model to compromised partner credentials, over-broad support access and third-party admin tooling. Internal-only reduces internet-facing attack surface but does nothing about insider misuse, and it is precisely the assumption attackers exploit.
• Anchor on impact. 300,000 patients' names and payment tokens means high confidentiality impact, likely regulatory notification duties and reputational exposure. High impact plus moderate-to-high likelihood should map to a high target verification level, which in turn mandates depth and independence: documented design review, code review of the authentication and storage paths, dynamic testing and an independent penetration test, with retained evidence for each ASC.
• Note the sequencing consequence. The target verification level is set during planning and is an input to ASC selection. If the level is lowered after the ASC set is chosen, the control set will be under-specified and the verification effort will not match the risk.
• Offer a legitimate path if the business pushes back. A lower level is only defensible if the impact or likelihood assessment changes on evidence, for example tokenised data that removes the app from scope of the card-data requirements. Absent that, the correct instrument is a documented risk acceptance with an expiry date and compensating controls, signed by the application owner, and recorded in the application's security file so the next reviewer sees the reasoning rather than a silent downgrade.

Answer: treat it as an ONF deficiency with an owner and a date, not as an absence of controls.

1. Do not invent a parallel control set. A project-local spreadsheet of mobile rules becomes shadow governance and will not be verified or maintained. Anything used must enter the ASC library through the ONF change process, even if that entry is provisional.
2. Draft provisional ASCs from an existing catalogue. Mobile platform hardening guides and MASVS categories give defensible source material. Create candidate ASCs covering secure storage of tokens, platform keychain use, certificate pinning, root/jailbreak detection policy, IPC exposure and WebView hardening. Mark them as provisional with an owner and a 30-day review date, and record the source so the review is a confirmation, not a rewrite.
3. Reuse the generic ASCs. Most of the 180 ASCs already apply - authentication, session management, cryptography, logging, input validation, error handling. The genuine gap is small; framing it that way removes the excuse to skip everything.
4. Sequence the nine weeks around verification. Select and document the ASC set in weeks one to three, implement in parallel with a threat model in week two, and book the independent test for weeks seven to eight so a re-test fits before go-live. Evidence templates should be agreed before implementation, otherwise developers produce screenshots that the verifier cannot accept.
5. Record the residual gap. If provisional ASCs are still unratified at go-live, log the ONF deficiency with an owner and target date so the audit sees a managed backlog item rather than an unknown.