Scoping a Risk-Based Security Test Plan for a PCI Payment Portal
Meridian Assurance runs an online premium payment portal for 40,000 policyholders. Card payments are handled by a third-party iframe (SAQ A-EP scope), and a new REST API lets 120 broker partners submit quotes. Releases ship every two weeks. The team has one security champion at 0.5 FTE, no dedicated penetration tester, and an annual external penetration test scheduled in five months - after the next six releases. In the last release, a penetration test found stored XSS in the claims-upload feature only after deployment; the hotfix cost 90 person-hours and the partner API was unavailable for two days. The head of engineering wants a security test plan for the next two releases that 'covers everything' without adding headcount. The compliance manager needs evidence for the PCI DSS assessment, and the product owner wants no delay to the release train.
1. The head of engineering asks for a plan that 'covers everything'. How do you scope security testing for the next two releases, and what artefacts do you produce?
Read the worked answer
Start from assets and change, not from a checklist of techniques.
Scoping logic
- Identify what is worth attacking: cardholder data flows through the iframe integration (SAQ A-EP still makes you responsible for your own page integrity, script inventory and CSP), broker credentials and quote data in the new API, and claims documents (previously hit by stored XSS).
- Threat-model each changed feature (e.g. STRIDE over the broker API: spoofing via token replay, elevation via missing object-level checks, tampering with quote values).
- Derive abuse cases from the threats, then rank by exposure x impact x likelihood, and confirm the ranking with the risk owner.
- Defer deliberately: record out-of-scope items with a reason and a named acceptor, and a date to revisit.
Artefacts: a security test plan (scope, out-of-scope with rationale, environments, test data, roles, schedule mapped to sprints, entry/exit criteria), the threat models, abuse-case test conditions traced to security requirements (OWASP ASVS as the baseline), and risk-register entries with owners and expiry.
'Cover everything' with 0.5 FTE and one annual penetration test spreads effort so thin that late discovery repeats - the previous XSS shipped because no test targeted the upload path during the sprint. A risk-based scope is defensible only if the exclusions are written down and accepted. The annual penetration test should also be re-scoped to attack the new API rather than repeat generic scanning.
2. Define entry and exit criteria for a sprint-level security test and explain how the work fits two-week sprints with 0.5 FTE.
Read the worked answer
Entry criteria
- Threat model updated for the stories in scope.
- Security acceptance criteria written and agreed with the product owner.
- Test environment available with masked or synthetic data, and test accounts for every relevant role.
- Build deployed and stable, scanner and configuration baselines available.
- Scope, stop conditions and authorisation for any intrusive testing agreed in writing.
Exit criteria
- Every in-scope security requirement has a recorded result with evidence.
- No open critical or high finding without a documented risk acceptance signed by the risk owner, with an expiry date.
- Fixed findings retested and passed.
- Dependency, secret and configuration scans show no known-exploited component with an available fix, no exposed credentials, and no drift from the hardening baseline.
Fitting 0.5 FTE Shift repeatable work into automation that costs no human time: SCA, secret scanning and SAST in CI, DAST nightly. Spend the champion's hours where judgement is needed - threat modelling new or changed features during refinement, manual access-control and business-logic tests on the highest-risk story, and triage. Write security acceptance criteria into the definition of done so developers self-check. Never let the annual penetration test be the primary control; it verifies, it does not prevent.
3. What evidence and metrics do you give the PCI assessor and management, and what would you refuse to present as a 'pass'?
Read the worked answer
Evidence for the assessor: the approved test plan and threat models; test cases traced to requirements and ASVS items; execution records showing date, environment, accounts and tester; finding records with severity, status, owner and retest evidence; risk acceptances with named owner and expiry; tool configurations and scan reports; and proof that authenticated scanning actually reached authenticated pages.
Metrics for management: percentage of security stories with acceptance criteria, findings by severity over time, mean time to remediate by severity, percentage of in-scope ASVS requirements verified, count and age of deferred risks, and coverage of changes in each release.
What I would refuse to call a pass
- A clean unauthenticated DAST run presented as security assurance - it mostly tested the login page.
- 'Zero findings' where scope excluded third-party scripts or the broker API.
- A finding closed without retest evidence, or on the strength of a scanner re-run alone.
- Scans of an environment that differs from production in a security-relevant way (gateway policies, TLS termination, WAF rules).
A pass means the exit criteria were met within a defined scope with residual risk explicitly accepted by someone with authority - not that no findings exist. Saying that plainly protects both the release decision and the audit position.