The Patient Portal Requirement That Cannot Be Tested
A healthcare portal team is finalizing requirements for a 12,000-user patient portal. Compliance states that patient records must be retained with a full audit trail for six years. The product owner's draft requirement reads: "All data must be encrypted at rest and access must be secure." Marketing wants a 30-day "remember me" option and plans to enable it on four lobby kiosks in clinics where patients self-check-in. The SSO integration uses a third-party identity provider that will store user attribute mappings. A compliance audit is 10 weeks away. A developer asks whether the kiosks can reuse the same 30-day session cookie as the mobile app. No security acceptance criteria exist, and the test lead says no meaningful test can be written from the current wording.
1. Rewrite the encryption and access requirement into verifiable acceptance criteria, and identify which single requirement is most likely to fail a security review.
Read the worked answer
Split the compound sentence into separately testable requirements, because "secure access" has no pass/fail state.
- Encryption at rest: data stores use AES-256 with keys held in a managed KMS, rotated at least annually, and key access is logged. Test: inspect storage config and key policy.
- Encryption in transit: TLS 1.2+ with approved cipher suites between browser, portal, IdP and database. Test: scanner output plus negative test with TLS 1.0.
- Authentication: MFA for all clinical staff; session idle timeout defined per device class.
- Authorization: every record access is checked against patient relationship, with an audit event written for each read.
The 30-day remember-me token on shared lobby kiosks is the requirement most likely to fail review. A persistent token on a device that many unidentified people touch breaks the attribution the audit trail depends on: the log would say "patient X opened the record" when the next person at the kiosk simply resumed the session. The mobile app is a personally held device, so the same token lifetime is not equivalent risk.
Do not just delete the feature. Replace it: on kiosks, disable remember-me, enforce a short idle timeout (for example two minutes), clear the session on check-in completion, and require re-authentication. Record the decision and its rationale so the auditor sees that device context drove the control, not convenience.
2. Reconcile the six-year audit retention requirement with data minimization and with the third-party identity provider storing attribute mappings.
Read the worked answer
These are not in conflict once you separate what is retained from what is collected.
Audit retention is an obligation about event records: who accessed which record, when, from where, and what changed. That evidence does not require retaining duplicate copies of clinical content or unnecessary personal attributes. So the requirement should be written as: audit events retained six years, immutable (append-only or WORM storage), time-synchronized, and searchable within a defined retrieval time.
Data minimization applies to the collection surface. Enumerate the exact attributes the portal needs from the IdP to make authorization decisions. If the IdP defaults to sending department, job title, phone and manager, those fields become personal data held in a third system with its own breach exposure. Request only the claim set the authorization rule actually reads.
The third-party IdP must be treated as in scope, not as an exception. Contractually require: attribute retention limits, deletion on termination, breach notification timelines, audit log export in a format that joins to portal events, and confirmation of which sub-processors touch the attributes. Add a test that confirms the portal still denies access correctly if an attribute is missing from the IdP response.
Finally, distinguish retention from deletion. A six-year audit log plus a two-year deletion policy for inactive accounts is coherent only if the audit events survive account deletion without carrying the deleted user's full profile.
3. The test team says it cannot test the current requirements. What artifact do you produce, and what does it contain?
Read the worked answer
Produce a security requirements traceability matrix plus a misuse-case set, before the test phase starts.
Each row carries: requirement ID, the verifiable acceptance criterion, data classification and threat reference, test method (automated, manual, inspection, penetration test), environment needed, and the audit control it satisfies. The matrix makes gaps visible: a requirement with no test method is unverified, and a test with no requirement is either gold-plating or a real control that was never specified.
Pair it with abuse cases derived from threat modeling, because acceptance criteria alone only test that the system does what it should. Add cases such as: reuse a remember-me token after logout, replay a session cookie from a different device, request another patient's record by changing an ID, and present an IdP assertion with an unexpected claim set. These map back to the same requirement IDs and are what the auditor will ask about under access control.
Deliverables are only useful if they are maintained. Assign ownership, store the matrix with the requirement baseline, and report pass/fail per criterion rather than per test count. A test lead who can say "29 of 31 access-control criteria verified, 2 blocked by missing kiosk hardware" has given the audit far more than a percentage.