As you've already surmised, a metric like "Attack Success Rate <= 0.001%" isn't a particularly useful test metric for an acceptance text.
Have a look at this page. It says:
Provider systems SHALL resist unauthorised, accidental or unintended usage and provide access only to legitimate users.
Please refer to the Security guidance page for technical details.
Now, of course, that's not a testable requirement; it is a wish. However, if you go to the Security guidance page that is linked there, you will find (among other things) this:
Secure connection negotiation
SHALL only accept connections from the Spine Secure Proxy (SSP)
SHALL authenticate the SSP prior to responding to any requests using its client certificate
SHALL only permit approved supported ciphers to be utilised
SHALL only accept encrypted connections and drop connection attempts presented over insecure protocols
SHALL only accept requests for its allocated address space identifier (ASID), as specified by the Ssp-To header on its
matching endpoint URL
SHALL check that the Ssp-InteractionID value is consistent with the endpoint being requested
SHALL check for the presence of all SSP headers
SHALL check that an authorization bearer token is present and correctly formed
MAY authorise access to API endpoints through examining acceptable values in the JSON Web Tokens (JWT) requested_scope claim
SHALL risk-manage the security of the endpoints of the Transport Layer Security (TLS) communications, so as to prevent inappropriate risks (for example, audit logging of the GET parameters into an unprotected audit log)
Ah, now we're getting somewhere. For the most part, these are testable requirements. Not only are they specific and testable, they also provide a detailed outline of your security strategy.