Q23 of 24 · Security

How do you write a negative security test plan for a feature that handles sensitive PII?

SecuritySeniorsecuritypiidata-protectiongdprnegative-testingtest-designsenior

Short answer

Short answer: Map every point where PII enters, moves through, and exits the system. For each point, write negative cases: accessing another user's PII (IDOR), receiving PII in error responses, PII surviving deletion, PII in URLs (which are logged), and PII in logs. Assert no leakage at each node.

Detail

A negative security test plan for PII is structured around data flow, not around features. Start with a data flow diagram — draw every point the data touches.

Data flow mapping:

  1. Entry: the form or API endpoint where PII is submitted (name, address, phone, tax ID, payment card details)
  2. Storage: database tables and columns, file storage (uploaded documents), cache layers
  3. Processing: batch jobs, export functions, PDF generation, email sending
  4. Transmission: internal service-to-service API calls, third-party integrations (payment processors, analytics)
  5. Display: user profile pages, admin dashboards, export files
  6. Deletion: soft delete vs hard delete; data retained for legal purposes

Negative test cases per node:

Entry:

  • Submit PII for User A, then retrieve it as User B (IDOR test)
  • Submit a PII field via the wrong endpoint (no authorisation check)
  • Submit PII that should be rejected (SSN in a text field with no validation)

Storage:

  • Verify that stored card data is masked (only last 4 digits stored, no CVV at rest)
  • Verify database fields containing PII are encrypted at column level if policy requires it

Transmission:

  • Verify internal service-to-service calls transmit PII over TLS
  • Verify third-party payloads do not include more PII than required

Display:

  • Verify exported CSV files are not accessible without authentication
  • Verify admin dashboards mask full SSN/card numbers

Deletion:

  • Delete a user account, then search the API for any remaining references to their PII
  • Verify hard delete actually removes the data, not just marks it inactive

Logs:

  • Perform a PII-related action with a distinctive test value
  • Search application logs for that value — it must not appear

// WHAT INTERVIEWERS LOOK FOR

Data flow mapping as the test design technique — not ad hoc test cases. Covers all lifecycle stages including deletion and logs. Shows awareness of both IDOR and data retention obligations.