# Verixa Penetration Testing Engagement Plan

**Version:** v8.1 | **Date:** June 2026 | **Status:** Inspector findings IR-01 through IR-15 corrected — see CHANGELOG
**Document ID:** VRX-SEC-PENTEST-001
**Classification:** CONFIDENTIAL — Security Sensitive
**Distribution:** Authorized Personnel Only

---

## CHANGELOG

### v8.1 (June 2026) — Inspector Findings IR-01 through IR-15 Corrected

| Change | Description |
|---|---|
| KD-001 restored | Authority profiles gate incorrectly — was incorrectly replaced with JWT algorithm confusion in v8.0. Original v7 KD-001 content restored. JWT confusion entry removed from KD register. |
| KD-004 restored | Webhook SSRF (user-supplied webhook_url, only format validation, no IP/hostname blocklist) — was incorrectly overwritten with background job RBAC content in v8.0. Webhook SSRF content restored. |
| KD-005 added | Background job RBAC (suspected missing guards on 31 job endpoints) added as a new, distinct KD entry separate from KD-004. |
| G-2 corrected | 30-day grace period removed. Zero open Highs required at go-live. Exception permitted only for non-GxP-impacting findings with explicit QA-signed risk acceptance per finding. Open High on any GxP surface = blocked regardless of age or risk acceptance. |
| G-9 added | HITL (Human-in-the-Loop) gate for critical AI paths added as mandatory go-live gate. Evidence: HITL config table + executed workflow showing AI output to human review to e-signature. |
| Test accounts restored to 11 | Auditor role account (account 6) and no-tenant-membership account (account 11) were missing from v8.0 list of 10. Both restored. Full canonical list now 11 accounts. |
| JOB-05 added | Audit trail verification for mutating background jobs. |
| JOB-06 added | Tenant isolation for cross-tenant background jobs using TDAL context. |
| JOB-07 added | Queue payload validation — malformed/oversized payloads must be rejected gracefully. |
| Test case count corrected | Claim of 180 test cases corrected to "153 numbered test case IDs across 22 attack surfaces (pending full inventory reconciliation — see Appendix C)". |
| Phase model corrected | Plan now states 10 phases (Phase 0 through Phase 9) throughout. |
| Regulatory language corrected | Overstated regulatory language replaced with accurate framing per CANONICAL_REGISTER.md. |
| CANONICAL_REGISTER.md created | Single source of truth register created. All future document generation must reference it. |
| Appendix B updated | Findings register updated from PENTEST-001 through PENTEST-005 to PENTEST-001 through PENTEST-006; D-6 deliverable updated to reference G-1 through G-9. |
| Appendix C added | Test case count reconciliation note added. |

### v8.0 (June 2026) — Review Corrections Applied

| Change | Description |
|---|---|
| Version header | Updated to v8.0, June 2026, added review correction annotation |
| INSERT fields replaced | All `[INSERT: ...]` fields replaced with `[REQUIRED BEFORE SIGN-OFF: <description>]` for visual distinction |
| KD-002 reclassification | Reclassified from High to Critical; rationale added (unkeyed SHA-256, TenantId exclusion, ALCOA+ Original, patient-safety impact) |
| KD-003 split | Split into KD-003a (systemPrompt exposure, High) and KD-003b (overrideResult() without e-sig, Critical) with separate CAPA references |
| Go-live gates G-7 and G-8 added | G-7: IMP-02/IMP-03 impersonation audit attribution evidence; G-8: ESIG-09b concurrent signing token reuse retest |
| ASVS decision note | Formal note in Section 2 documenting ASVS v4.0.3 decision with rationale and v5.0 migration commitment |
| JOB-04 added | RBAC sweep of all 31 background job endpoints — automated scan, Custom Python + Logger++ |
| AI-09 annotation | Added mapping note to KD-003a; test must not be marked Pass until KD-003a CAPA is closed |
| RBAC-15 Phase 0 baseline | Phase 0 checklist updated with automated route-permission scan and baseline count documentation |
| KD-002 go-live gate | KD-002 now Critical; falls under G-1 (zero Critical findings open) in addition to G-5 |
| Appendix B added | Execution Document: expanded findings register (PENTEST-001 to PENTEST-005), full D-1 to D-7 deliverables table, SHA-256 artifact hash in evidence standard, updated out-of-scope list |
| Testing cadence | Section 10 updated with AI model version/provider/prompt change trigger |
| Section 15 updated | Pre-Confirmed Vulnerabilities updated for KD-002 Critical reclassification and KD-003 split |

---

## 1. Engagement Overview

### 1.1 Objective

This document defines the authorized penetration testing engagement plan for the Verixa platform — a GAMP 5 Category 5, GxP-regulated, multi-tenant AI eQMS SaaS application. The purpose of this engagement is to:

1. Independently verify security controls prior to production deployment and on a recurring annual basis.
2. Identify exploitable vulnerabilities across authentication, authorization, tenant isolation, audit trail integrity, AI/ML attack surface, e-signature workflows, and cloud infrastructure.
3. Produce evidence-quality findings that support the validation and security assurance program per the agreed validation strategy in the overall validation plan.
4. Provide closure evidence for Known Defects (KD series) identified during internal code review.
5. Confirm go-live gate compliance per Section 5.3 before any production release.

This engagement covers 153 numbered test case IDs across 22 attack surfaces (pending full inventory reconciliation — Appendix C). This plan applies to all annual penetration test cycles and all materially significant pre-release tests as defined in Section 10.

### 1.2 Methodology

Testing follows a gray-box approach with white-box review of critical paths:

- **Gray-box testing**: Testers are provided with test accounts across all defined roles (see Section 4.2). No source code provided initially; white-box supplements are listed in Section 12.
- **White-box review**: Targeted code review for audit trail chain, HITL gate bypass, tenant isolation, and AI/ML attack surface (see Section 12).
- **Standards basis**: OWASP ASVS v4.0.3 (see Section 2 for version rationale), OWASP WSTG v4.2, OWASP API Security Top 10 (2023), NIST SP 800-115.
- **Regulatory integration**: Findings mapped to 21 CFR Part 11, EU Annex 11, QS-series controls from Verixa CLAUDE.md, and GMLP principles where applicable.

### 1.3 In-Scope Assets

| Asset | Environment | Test Type | Notes |
|---|---|---|---|
| Verixa web application (all modules) | Staging | Authenticated web app testing | All role levels |
| Verixa REST API (all endpoints) | Staging | Authenticated API testing | Including undocumented routes |
| Authentication service (JWT, MFA, SSO) | Staging | Full auth testing | Session, token, MFA bypass |
| RBAC / permission system | Staging | Horizontal and vertical privilege escalation | All 31 background job endpoints (see JOB-04) |
| Tenant isolation layer (TDAL + RLS) | Staging | Cross-tenant data access | Multi-tenant boundary testing |
| Audit trail service | Staging | Integrity, forgery, completeness | Including chain verification |
| E-signature workflows | Staging | Bypass, replay, concurrent signing | ESIG series tests |
| AI/ML surface (Mira copilot, prediction engine) | Staging | Prompt injection, HITL bypass, output manipulation | AI series tests |
| Background job endpoints | Staging | RBAC enforcement | All 31 endpoints — see JOB-04 through JOB-07 |
| Cloud infrastructure (AWS/GCP config) | Staging + Production equivalent config | Configuration review | No live production exploitation |
| CI/CD pipeline configuration | Review only | Static review | No live CI/CD system interaction |
| Secrets management | Staging | Secrets exposure, rotation verification | |
| File upload/download endpoints | Staging | Unrestricted upload, path traversal | |
| Integration connectors / webhooks | Staging | SSRF, injection, authentication | Includes webhook SSRF — KD-004 |

### 1.4 Out of Scope

The following are explicitly excluded from this engagement:

- **Production environment** — all active testing against production systems is prohibited. Configuration review of infrastructure-as-code equivalent to production is permitted.
- **Social engineering, phishing, physical access** — not authorized.
- **Denial-of-service (DoS/DDoS)** — not authorized unless separately scoped with infrastructure team approval.
- **Stealth/persistence testing** — all testing is overt and cooperative.
- **Customer tenant data** — no real customer data in scope. Synthetic test data only.
- **Third-party LLM provider infrastructure** (Anthropic, Azure OpenAI) — infrastructure testing of providers is out of scope.
- **Design-partner infrastructure** — any infrastructure owned or operated by Verixa design partners is out of scope.
- **Backup restoration validation** — this is a separate Annex 11 §7/§10 controlled activity and must be scheduled independently.
- **Malware deployment, credential exfiltration, lateral movement** — prohibited unconditionally.

---

## 2. Standards and Methodology

### 2.1 Applicable Standards

| Standard | Version | Application |
|---|---|---|
| OWASP ASVS | **4.0.3** (see decision note below) | Primary web application security verification |
| OWASP WSTG | 4.2 | Web application testing methodology |
| OWASP API Security Top 10 | 2023 | API security testing |
| NIST SP 800-115 | 2008 | Security testing process discipline |
| NIST CSF | 2.0 | Management crosswalk |
| ISO/IEC 27001 | 2022 | ISMS alignment |
| ISO/IEC 27002 | 2022 | Control implementation |
| 21 CFR Part 11 | Current | Electronic records and signatures |
| EU Annex 11 | Current | Computerised systems |
| EU Annex 22 (Draft 2025) | Draft | AI/ML in pharmaceutical manufacturing |
| GMLP (10 principles) | Current | Good Machine Learning Practices |

### 2.2 ASVS Version Decision Note

**Decision:** This engagement uses OWASP ASVS **v4.0.3**.

**Rationale:** ASVS v5.0 was released after this engagement was scoped and contracted. The test cases in this plan, the tooling configurations, and the tester qualifications were validated against v4.0.3. Migrating to v5.0 mid-engagement would require re-scoping, re-training, and re-validating all test cases — introducing risk without commensurate benefit for this cycle.

**Known gaps:** ASVS v5.0 introduces restructured verification levels, updated OAuth/OIDC test cases, and revised API security controls. These gaps have been assessed and partially mitigated by incorporating OWASP API Security Top 10 (2023) and supplemental test cases developed by the test lead.

**Commitment:** The annual retest scheduled for [REQUIRED BEFORE SIGN-OFF: insert annual retest target date, expected Q2/Q3 of next year] will migrate to ASVS v5.0. A formal review of v5.0 requirements vs. this plan's test case coverage must be completed no later than [REQUIRED BEFORE SIGN-OFF: insert date at least 60 days before next retest kick-off] and documented as a pre-engagement deliverable.

**Decision owner:** [REQUIRED BEFORE SIGN-OFF: name and title of security governance owner who approved this version decision]

**Decision date:** [REQUIRED BEFORE SIGN-OFF: date of governance approval]

---

## 3. Rules of Engagement and Scope Boundaries

### 3.1 Written Authorization

Active testing MUST NOT begin until all fields in this section are signed and on file.

| Field | Required Value |
|---|---|
| Authorizing executive name | [REQUIRED BEFORE SIGN-OFF: full name of executive authorized to approve penetration testing of Verixa systems] |
| Authorizing executive title | [REQUIRED BEFORE SIGN-OFF: title and legal authority of authorizing executive] |
| Legal entity owning the systems | [REQUIRED BEFORE SIGN-OFF: full legal entity name (e.g., "Verixa Inc." or applicable holding entity)] |
| Tester / vendor organization | [REQUIRED BEFORE SIGN-OFF: full legal name of testing firm or named individual tester(s)] |
| Tester qualifications on file | [REQUIRED BEFORE SIGN-OFF: confirm CVs and certifications received and filed per Section 13] |
| NDA / confidentiality agreement reference | [REQUIRED BEFORE SIGN-OFF: document reference number and execution date of NDA covering this engagement] |
| Statement of Work / contract reference | [REQUIRED BEFORE SIGN-OFF: SOW or contract reference number governing this engagement] |
| Approved target list reference | [REQUIRED BEFORE SIGN-OFF: confirm Section 1.3 table has been reviewed and signed off by authorizing executive] |
| Test window — start date | [REQUIRED BEFORE SIGN-OFF: exact calendar date testing may begin (YYYY-MM-DD)] |
| Test window — end date | [REQUIRED BEFORE SIGN-OFF: exact calendar date testing must conclude (YYYY-MM-DD)] |
| Approved test hours | [REQUIRED BEFORE SIGN-OFF: e.g., "09:00-18:00 UTC weekdays only" or "any hours"] |
| Emergency stop contact — name | [REQUIRED BEFORE SIGN-OFF: full name of person who can immediately halt testing] |
| Emergency stop contact — phone | [REQUIRED BEFORE SIGN-OFF: direct mobile number, 24/7 reachable during test window] |
| Emergency stop contact — email | [REQUIRED BEFORE SIGN-OFF: email address for emergency communication] |
| Escalation path for critical findings | [REQUIRED BEFORE SIGN-OFF: named recipient(s) for immediate Critical/High severity notification, and SLA (e.g., "within 2 hours for Critical, within 24 hours for High")] |
| Data handling — evidence retention policy | [REQUIRED BEFORE SIGN-OFF: how long tester may retain evidence, where stored, destruction date] |
| Data handling — evidence encryption requirement | [REQUIRED BEFORE SIGN-OFF: encryption standard required for stored evidence (e.g., AES-256)] |
| Prohibited actions confirmation | Destructive testing, persistence installation, stealth/evasion, malware deployment, credential theft or exfiltration, DoS/DDoS, testing of out-of-scope systems — ALL PROHIBITED unless separately and explicitly authorized in writing |

**Authorization signature block:**

Authorized by: [REQUIRED BEFORE SIGN-OFF: signature, printed name, title, date]

Accepted by (tester/vendor): [REQUIRED BEFORE SIGN-OFF: signature, printed name, title, date]

Witnessed by (security governance): [REQUIRED BEFORE SIGN-OFF: signature, printed name, title, date]

### 3.2 Environment

- All active testing occurs in the designated **staging environment only**.
- Production environment is prohibited for active testing.
- Testers must confirm environment identity (URL, host, TLS certificate) before each session.
- Any accidental access to or impact on production must be immediately reported to the emergency stop contact.
- Staging environment must be a functionally equivalent replica of production for the test to be valid as pre-release evidence.

### 3.3 Tester Independence

- No tester may have been involved in developing the system under test within the 12 months prior to testing.
- No tester may hold an employment or contractor relationship with Verixa during the engagement (arms-length vendor preferred; internal red team permissible only with documented independence declaration).
- Independence declarations must be on file before testing begins.
- See Section 13 for full qualification and independence requirements.

---

## 4. Pre-Engagement Requirements

### 4.1 Pre-Engagement Checklist

All items must be confirmed complete before active testing begins.

| # | Requirement | Status | Owner | Notes |
|---|---|---|---|---|
| PRE-01 | Written authorization executed (Section 3.1 fully completed and signed) | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Security Lead | Blocking gate |
| PRE-02 | NDA and SOW on file | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Legal | |
| PRE-03 | Tester CVs, certifications, and independence declarations received and filed | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Security Lead | |
| PRE-04 | Staging environment availability confirmed | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Platform Engineering | Replica of production |
| PRE-05 | Test accounts provisioned per Section 4.2 (all 11 accounts) | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Platform Engineering | |
| PRE-06 | Emergency contact confirmed reachable | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Security Lead | |
| PRE-07 | Tester briefed on prohibited actions | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Security Lead | |
| PRE-08 | Evidence storage and encryption solution configured | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Tester | Per Section 3.1 data handling |
| PRE-09 | Verixa internal monitoring team notified of test window | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Security Lead | Prevents false-positive incident response |
| PRE-10 | Latest code deployed to staging (commit hash documented) | [REQUIRED BEFORE SIGN-OFF: Confirmed — commit hash: ____________] | Platform Engineering | Hash required for report traceability |
| PRE-11 | Known Open Defects (Section 8) reviewed with tester — all 6 KDs: KD-001, KD-002, KD-003a, KD-003b, KD-004, KD-005 | [REQUIRED BEFORE SIGN-OFF: Confirmed / Not Confirmed] | Security Lead | Tester must confirm KD scope |
| PRE-12 | **Automated route-permission scan complete — total route count documented as baseline for RBAC-15 sweep** | [REQUIRED BEFORE SIGN-OFF: Confirmed — total route count: ____________] | Security Lead | Required baseline; RBAC-15 cannot be closed without this count |

### 4.2 Test Accounts

The following test accounts must be provisioned in the staging environment before testing begins. All accounts must be isolated to a dedicated test tenant and must have no access to any production or customer data.

**Total: 11 accounts. v8.0 incorrectly listed 10 — auditor role (account 6) and no-tenant account (account 11) were missing. Restored in v8.1.**

| # | Username | Role | Tenant | Purpose |
|---|---|---|---|---|
| 1 | pentest-superadmin@verixa-test.internal | super_admin | Platform | Highest privilege escalation target |
| 2 | pentest-platformadmin@verixa-test.internal | platform_admin | Platform | Platform-level administration |
| 3 | pentest-admin-t1@verixa-test.internal | admin | Tenant A | Tenant A administration |
| 4 | pentest-qualitylead-t1@verixa-test.internal | quality_lead | Tenant A | Quality lead approval workflows |
| 5 | pentest-reviewer-t1@verixa-test.internal | reviewer | Tenant A | Reviewer workflow access |
| 6 | pentest-auditor-t1@verixa-test.internal | auditor | Tenant A | Audit-read access testing |
| 7 | pentest-viewer-t1@verixa-test.internal | viewer | Tenant A | Minimum privilege read-only |
| 8 | pentest-admin-t2@verixa-test.internal | admin | Tenant B | Cross-tenant isolation testing |
| 9 | pentest-reviewer-t2@verixa-test.internal | reviewer | Tenant B | Cross-tenant isolation testing |
| 10 | pentest-viewer-t2@verixa-test.internal | viewer | Tenant B | Cross-tenant isolation testing |
| 11 | pentest-notenantmember@verixa-test.internal | (no membership) | None | Unauthenticated/tenant-less access |

**Account provisioning confirmation:** [REQUIRED BEFORE SIGN-OFF: confirm all 11 accounts provisioned, credentials securely delivered to tester via encrypted channel]

---

## 5. Acceptance Criteria and Release Gate

### 5.1 Severity Scale

| Severity | Definition | Regulatory Dimension |
|---|---|---|
| **Critical** | Exploitable vulnerability with direct impact on patient safety, data integrity, multi-tenant isolation, e-signature bypass, or GxP record falsification | 21 CFR Part 11, EU Annex 11, ALCOA+ violation potential |
| **High** | Significant security control failure; exploitable with moderate effort; material impact on confidentiality, integrity, or availability of GxP records | Regulatory risk; likely audit finding |
| **Medium** | Security weakness requiring specific conditions to exploit; moderate impact on security posture | May constitute audit observation |
| **Low** | Defense-in-depth weaknesses; limited direct exploitability | Best-practice gap |
| **Informational** | Observation, configuration note, or improvement recommendation | No immediate risk |

### 5.2 Remediation SLAs

| Severity | Maximum Time to Remediate (from finding confirmation) | Retest Required? |
|---|---|---|
| Critical | 7 calendar days | Yes — mandatory before go-live or next release |
| High | 30 calendar days | Yes — mandatory before go-live or within next release cycle |
| Medium | 90 calendar days | Yes — within next quarterly review |
| Low | 180 calendar days or next annual test | At discretion of security lead |
| Informational | Best effort | At discretion |

### 5.3 Go-Live Gate

The following gates must ALL be passed before any production release. Gates are binary: Pass or Blocked. No partial credit.

| Gate | Requirement | Status |
|---|---|---|
| **G-1** | Zero Critical-severity findings open | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-2** | Zero High-severity findings open. Exception permitted only for non-GxP-impacting findings with explicit QA-signed risk acceptance on file per finding. Any open High finding on a GxP surface (audit trail, e-signature, RBAC, tenant isolation, AI output) = blocked regardless of age or risk acceptance. | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-3** | All KD-series Known Defects with Critical or High severity have confirmed remediation evidence and retest Pass recorded (covers KD-001, KD-002, KD-003a, KD-003b, KD-004, KD-005) | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-4** | Pentest final report delivered, QA-reviewed, and Security Lead–accepted | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-5** | KD-002 audit trail chain integrity — retest Pass evidence on file (HMAC-SHA256 keyed; TenantId in payload; chain verification confirmed) | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-6** | KD-003b overrideResult() e-signature bypass — CAPA closed, retest Pass evidence on file (e-sig gate active; HITL gate enforced before overrideResult() writes) | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-7** | **IMP-02 and IMP-03 impersonation audit attribution evidence filed and QA-approved** — test confirming impersonated actions are attributed to impersonator (with notation of original subject identity), not to subject user | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-8** | **ESIG-09b concurrent signing token reuse — retest evidence on file** — test confirming concurrent e-signature sessions cannot reuse each other's signing tokens | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |
| **G-9** | **HITL (Human-in-the-Loop) active and confirmed for all critical AI paths.** Evidence required: (1) HITL configuration table showing all critical AI paths (batch disposition, OOS classification, CAPA disposition, deviation classification) with human review gate active in hitl_gate_config; (2) Executed workflow evidence showing AI output → human review → e-signature flow completes correctly for at least one record in each critical path | [REQUIRED BEFORE SIGN-OFF: Pass / Blocked] |

**Go-Live Gate sign-off:** [REQUIRED BEFORE SIGN-OFF: Security Lead signature, date, and confirmation that all gates G-1 through G-9 are Pass]

---

## 6. Finding Lifecycle and QMS Integration

### 6.1 Finding Classification

All findings are classified using the severity scale in Section 5.1 and assigned a unique Finding ID in the format `PENTEST-NNN`. Every finding must include:

- Finding ID (PENTEST-NNN)
- Title
- Severity (Critical / High / Medium / Low / Informational)
- ASVS / WSTG / regulatory control mapping
- Affected asset and endpoint
- Evidence reference (screenshot, request/response, video, commit hash, log extract)
- SHA-256 hash of evidence package
- Reproduction steps (sufficient for independent verification)
- Impact statement (technical and regulatory)
- Remediation recommendation
- CAPA reference (if applicable)
- Retest status

### 6.2 Finding Closure

A finding may only be closed when:

1. The developer has implemented the fix and it has passed code review.
2. The fix has been deployed to staging.
3. The tester has independently retested and confirmed the vulnerability is no longer exploitable.
4. A retest evidence package (request/response, screenshot, or equivalent) has been filed.
5. The SHA-256 hash of the retest evidence package has been recorded.
6. The Security Lead has reviewed and approved closure.
7. If a CAPA was opened, CAPA closure is confirmed or confirmed in progress (per SLA).

Findings may not be closed by developer assertion alone. Independent retest is mandatory for Critical and High findings.

### 6.3 Escalation

| Trigger | Action | SLA |
|---|---|---|
| Critical finding discovered | Immediate notification to emergency contact and Security Lead | Within 2 hours of finding confirmation |
| High finding discovered | Notification to Security Lead | Within 24 hours |
| Finding suggests active exploitation of production | Halt testing; activate incident response; notify CTO and Security Lead | Immediately |
| Finding scope creep (testing touching out-of-scope asset) | Halt testing; notify Security Lead; document and discard any out-of-scope evidence | Immediately |

---

## 7. Pentest Evidence Governance

### 7.1 ALCOA+ Evidence Requirements

All pentest evidence is treated as regulated evidence and must meet ALCOA+ requirements:

| ALCOA+ Principle | Requirement |
|---|---|
| **Attributable** | Every evidence artifact labeled with tester name/ID, date, time, and engagement reference |
| **Legible** | Screenshots at sufficient resolution; request/response logs complete and readable |
| **Contemporaneous** | Evidence captured at time of finding; no reconstructed or recreated evidence |
| **Original** | Original captures preserved; no post-processing that alters content |
| **Accurate** | Evidence accurately represents the observed condition; no selective cropping to misrepresent |
| **Complete** | Full request and full response captured; partial captures require justification |
| **Consistent** | Evidence timestamps consistent with tester activity logs |
| **Enduring** | Evidence retained for the period specified in Section 3.1 data handling agreement |
| **Available** | Evidence accessible to Verixa QA on request within the engagement and retention period |

### 7.2 Document Control

- This document is version-controlled under Verixa's document control system.
- Document ID: VRX-SEC-PENTEST-001
- All revisions require Security Lead review and approval before distribution.
- Printed copies are uncontrolled. Always verify version against the document control system.

### 7.3 Deliverables Register

See Appendix B for the full D-1 through D-7 deliverables table with owner and due date columns.

---

## 8. Known Open Defects

> **This register contains 6 Known Defects (KD-001, KD-002, KD-003a, KD-003b, KD-004, KD-005). 2 are Critical (KD-002, KD-003b). 4 are High (KD-001, KD-003a, KD-004, KD-005). All 6 must have CAPA references populated before Phase 0 sign-off. All 6 are pre-registered as PENTEST-001 through PENTEST-006 in Appendix B.**

The following defects were identified during internal code review prior to the penetration test engagement. Testers must review all KD entries before testing. The penetration test must attempt to demonstrate exploitability for each KD finding to determine actual risk severity in a deployed environment.

### KD-001 — Authority Profile Gate Misconfiguration

| Field | Value |
|---|---|
| **ID** | KD-001 |
| **Title** | 4 authority profiles gate incorrectly — profiles allow actions they are configured to prevent |
| **Severity** | High |
| **Status** | Open |
| **Source** | Internal code review |
| **Asset** | Authority Profile module — AUTHZ-006 rule evaluation engine |
| **Description** | Four of the 37 authority profiles in the Verixa system evaluate gate conditions incorrectly, allowing actions that the profile configuration is intended to prevent. Profile IDs are Unknown — must be identified before Phase 0 sign-off. This was the original v7 KD-001. It was incorrectly replaced with JWT confusion in v8.0. |
| **Regulatory Impact** | 21 CFR 11.10(d) — access control bypass; EU Annex 11 §12 — computerised system access controls |
| **CAPA Reference** | [REQUIRED BEFORE SIGN-OFF: CAPA ticket reference number] |
| **PENTEST Test Reference** | AUTH-P-07 |
| **PRECONDITION** | Profile IDs to be confirmed and inserted here before engagement begins: Profile 1 ID: ___ Profile 2 ID: ___ Profile 3 ID: ___ Profile 4 ID: ___ |

### KD-002 — Audit Trail Chain Integrity (SHA-256 Unkeyed, TenantId Exclusion)

| Field | Value |
|---|---|
| **ID** | KD-002 |
| **Title** | Audit trail chain: unkeyed SHA-256 hash, TenantId excluded from chain input |
| **Severity** | **Critical** |
| **Status** | Open |
| **Source** | Internal code review |
| **Asset** | Audit trail service (`audit_trail` table, chain verification function) |
| **Description** | The audit trail integrity chain uses an unkeyed SHA-256 hash of record fields to link entries. TenantId is excluded from the chain input. |
| **Rationale for Critical Classification** | Unkeyed SHA-256 means any party with database write access (or who can inject SQL) can recompute a valid hash after modifying audit records — there is no key material that prevents a forger from producing a matching chain. The exclusion of TenantId from the chain input means audit records can be transplanted from one tenant's chain to another without breaking chain verification. Under 21 CFR 11.10(e) and ALCOA+ Original, tamper-evidence that can be bypassed at the application layer fails the regulation. **Patient/data-integrity impact dimension: Critical** — batch records and deviation conclusions could be falsified without detection. A regulatory inspector who relies on the audit trail as the system of record would be presented with undetectable falsified evidence. |
| **Regulatory Impact** | 21 CFR 11.10(e) — audit trail tamper-evidence failure; ALCOA+ Original — original record not protected; EU Annex 11 §9 — audit trail integrity |
| **CAPA Reference** | [REQUIRED BEFORE SIGN-OFF: CAPA ticket reference number] |
| **Go-Live Gate** | G-1 (zero Critical findings open) AND G-5 (KD-002 retest Pass evidence: HMAC-SHA256 keyed; TenantId in payload; chain verification confirmed) |
| **PENTEST Test Reference** | AUDIT-03, AUDIT-05 |

### KD-003a — AI Copilot System Prompt Exposure

| Field | Value |
|---|---|
| **ID** | KD-003a |
| **Title** | AI gateway user-supplied systemPrompt; all 10 prompt injection tests describe.skip |
| **Severity** | High |
| **Status** | Open |
| **Source** | Internal code review |
| **Asset** | Mira AI copilot — `systemPrompt` configuration |
| **Description** | The Mira copilot system prompt, which contains proprietary model configuration, prompt engineering techniques, and potentially internal architecture references, can be extracted by a crafted user prompt via prompt injection. All 10 prompt injection test cases in the test suite are currently marked `describe.skip`, meaning the known injection surface is untested by automated test coverage. |
| **Regulatory Impact** | Intellectual property exposure; potential exposure of internal system configuration details that could assist further attacks. EU AI Act Art. 13 — transparency requirements do not require prompt confidentiality to users, but extraction of system prompt content can expose security-relevant architecture. OWASP LLM01; EU Annex 22 §7. |
| **CAPA Reference** | [REQUIRED BEFORE SIGN-OFF: CAPA ticket reference number — separate from KD-003b] |
| **PENTEST Test Reference** | AI-01, AI-03, AI-09 |

> **AI-09 Annotation:** This test case maps directly to KD-003a. The finding has been pre-confirmed via code review. The penetration test verifies scope completeness (confirms the full extent of extractable information), validates the fix post-remediation, and confirms no additional injection vectors exist beyond the identified path. **Do not mark AI-09 as Pass until KD-003a CAPA is closed and retest evidence is on file.**

### KD-003b — overrideResult() Writes LLM Output to GxP Records Without E-Signature

| Field | Value |
|---|---|
| **ID** | KD-003b |
| **Title** | `overrideResult()` writes arbitrary LLM-generated text to regulated GxP record fields without e-signature confirmation and without HITL gate |
| **Severity** | **Critical** |
| **Status** | Open |
| **Source** | Internal code review |
| **Asset** | AI/ML module — `overrideResult()` function; affected GxP tables: `complaints`, `deviations`, `capas`, `batch_records` |
| **Description** | The `overrideResult()` function allows AI-generated (LLM-produced) text to be written directly to regulated GxP record fields — including `complaints.root_cause`, `deviations.investigation_conclusion`, `capas.action_description`, and `batch_records.disposition` — without requiring an e-signature confirmation from the acting user and without passing through the HITL gate (`hitl_decisions` / `hitl_gate_config`). |
| **Rationale for Critical Classification** | This function writes arbitrary LLM text to regulated GxP fields (CAPA descriptions, deviation conclusions, batch dispositions) with no e-signature confirmation and no HITL gate. This is a direct violation of: (1) **QS-21** — AI output must not be written to GxP record fields without explicit human confirmation; (2) **EU Annex 22 §7** — human oversight of AI in critical GMP decisions is mandatory; (3) **21 CFR 11.50** — e-signature meaning and attribution requirements; (4) **ALCOA+ Attributable** — the record would be attributed to the system/AI rather than an identifiable human. AI-generated content entering GxP records without human attribution is an existential regulatory risk. An FDA inspector reviewing a deviation investigation whose conclusion was AI-written without a human e-signature would observe a direct 21 CFR Part 11 violation. |
| **Regulatory Impact** | 21 CFR 11.50 (e-signature attribution); 21 CFR 11.10(e) (audit trail — AI authorship not attributed); EU Annex 11 §9; EU Annex 22 §7; QS-21; ALCOA+ Attributable |
| **CAPA Reference** | [REQUIRED BEFORE SIGN-OFF: CAPA ticket reference number — separate from KD-003a] |
| **Go-Live Gate** | G-1 (zero Critical findings open) AND G-6 (KD-003b CAPA closed, retest Pass) AND G-9 (HITL active for all critical AI paths) |
| **PENTEST Test Reference** | AI-10, AI-11, AI-12 |

### KD-004 — Webhook SSRF

| Field | Value |
|---|---|
| **ID** | KD-004 |
| **Title** | Webhook SSRF: user-supplied webhook_url, only format validation, no IP/hostname blocklist |
| **Severity** | High |
| **Status** | Open |
| **Source** | Internal code review |
| **Asset** | `webhook-connector.ts:45`; `regulatory-impact.service.ts:511` |
| **Description** | The webhook connector accepts user-supplied `webhook_url` values and validates only the RFC URL format using `z.string().url()`. No IP range blocklist (RFC 1918: 10.x.x.x, 172.16-31.x.x, 192.168.x.x), no link-local blocklist (169.254.x.x), no hostname blocklist, and no DNS rebinding protection. The webhook test endpoint issues a HEAD request at registration time — SSRF is exploitable on registration, not only on trigger. The regulatory feed URL (`regulatory-impact.service.ts:511`) fetches tenant-configured `feed_url` without SSRF protection. |
| **Regulatory Impact** | OWASP API8:2023 — Server-Side Request Forgery; ASVS V10.3.2 |
| **CAPA Reference** | [REQUIRED BEFORE SIGN-OFF: CAPA ticket reference number] |
| **PENTEST Test Reference** | SSRF-01, SSRF-02, SSRF-03 |

### KD-005 — Background Job RBAC

| Field | Value |
|---|---|
| **ID** | KD-005 |
| **Title** | Background job RBAC: suspected missing guards on 31 job endpoints |
| **Severity** | High |
| **Status** | Open |
| **Source** | Internal code review |
| **Asset** | `packages/backend/src/jobs/` — all 31 background job endpoints |
| **Description** | Internal review indicates that not all background job trigger endpoints have explicit RBAC guards configured. Endpoints without guards return "Route does not have permission configuration" rather than `AUTHZ_ROLE_DENIED`, indicating missing permission checks rather than an authorization denial. Full verification requires the RBAC sweep in JOB-04. |
| **Regulatory Impact** | QS-7 — permission check on every route; 21 CFR 11.10(d) — access control |
| **CAPA Reference** | [REQUIRED BEFORE SIGN-OFF: CAPA ticket reference number] |
| **PENTEST Test Reference** | JOB-01, JOB-02, JOB-03, JOB-04, JOB-05, JOB-06, JOB-07 |

---

## 9. Test Cases — Master Checklist

### 9.1 Authentication (AUTH series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| AUTH-01 | JWT `alg: none` bypass | ASVS 3.5.3 | Manual + automated | Burp Suite | Server rejects tokens with `alg: none`; 401 returned |
| AUTH-02 | JWT algorithm confusion (RS256 to HS256) | ASVS 3.5.3 | Manual | Custom script | Server rejects algorithm-switched tokens |
| AUTH-03 | JWT expiry enforcement | ASVS 3.5.1 | Manual | Burp Suite | Expired tokens rejected with 401 |
| AUTH-04 | JWT secret brute-force resistance | ASVS 3.5.2 | Automated | jwt_tool | Secret not guessable; HS256 secret strength adequate |
| AUTH-05 | Refresh token rotation and invalidation | ASVS 3.5.4 | Manual | Burp Suite | Refresh token invalidated after use; replay rejected |
| AUTH-06 | MFA bypass | ASVS 2.8 | Manual | Burp Suite | MFA cannot be skipped; all MFA-required routes enforce it |
| AUTH-07 | Account lockout / brute-force protection | ASVS 2.2.1 | Automated | Burp Intruder | Lockout after configured failed attempts |
| AUTH-08 | Password reset token security | ASVS 2.3 | Manual | Burp Suite | Tokens single-use, time-limited, not guessable |
| AUTH-09 | SSO / SAML assertion replay | ASVS 3.7 | Manual | Burp Suite | Assertion replay rejected |
| AUTH-10 | Session fixation | ASVS 3.3 | Manual | Burp Suite | New session token issued on authentication |
| AUTH-P-07 | Authority profile gate evaluation — 4 failing profiles | KD-001; AUTHZ-006 | Manual + white-box | Burp Suite + Code review | Identified profiles do not allow actions they are configured to prevent. **PRECONDITION: 4 failing profile IDs must be recorded in KD-001 before this test runs.** |

### 9.2 Authorization and RBAC (RBAC series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| RBAC-01 | Vertical privilege escalation — viewer to quality_lead | ASVS 4.1 | Manual | Burp Suite | Operations requiring quality_lead rejected with AUTHZ_ROLE_DENIED |
| RBAC-02 | Vertical privilege escalation — admin to platform_admin | ASVS 4.1 | Manual | Burp Suite | Platform admin operations rejected for tenant admin |
| RBAC-03 | Horizontal privilege escalation — cross-user record access | ASVS 4.2 | Manual | Burp Suite | User A cannot read/write User B's records in same tenant |
| RBAC-04 | IDOR on GxP record IDs | ASVS 4.2.1 | Automated | Burp Intruder | Sequential/UUIDs return 403 for unauthorized requestors |
| RBAC-05 | Permission check missing on undocumented routes | ASVS 4.1 | Manual | Burp Suite | All routes return proper AUTHZ response, not 404 for auth bypass |
| RBAC-06 | Reviewer cannot approve own submissions | Domain-specific | Manual | Burp Suite | Self-approval rejected |
| RBAC-07 | Quality lead cannot skip review stage | Domain-specific | Manual | Burp Suite | Workflow stages enforced |
| RBAC-08 | Platform admin cannot access tenant business data | ASVS 4.1 | Manual | Burp Suite | Platform admin restricted to platform operations |
| RBAC-09 | Role assignment — only admin can grant roles | ASVS 4.1 | Manual | Burp Suite | Non-admin role grant rejected |
| RBAC-10 | Deleted user session invalidation | ASVS 3.3 | Manual | Burp Suite | Suspended/deleted user tokens rejected |
| RBAC-11 | Bulk operation RBAC enforcement | ASVS 4.1 | Manual | Burp Suite | Bulk endpoints enforce same RBAC as single-record endpoints |
| RBAC-12 | Export / report access control | ASVS 4.1 | Manual | Burp Suite | Export of records restricted to authorized roles |
| RBAC-13 | API key / service account RBAC | ASVS 4.1 | Manual | Burp Suite | Service accounts cannot exceed their defined permissions |
| RBAC-14 | Workflow state machine bypass | Domain-specific | Manual | Burp Suite | Cannot transition record to invalid state via direct API call |
| RBAC-15 | **Full route-permission coverage sweep** | ASVS 4.1 | Automated | Custom script | Every route in the application returns a configured AUTHZ response; count matches PRE-12 baseline |

> **RBAC-15 Note:** This test cannot be completed without the Phase 0 baseline route count established in PRE-12. The sweep must confirm every route in the documented baseline has a valid permission configuration. Any route returning "Route does not have permission configuration" is a finding at High or Critical severity depending on the operation.

### 9.3 Tenant Isolation (TENANT series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| TENANT-01 | Cross-tenant record read via direct ID | ASVS 4.2 | Manual | Burp Suite | Tenant B user cannot retrieve Tenant A records |
| TENANT-02 | Cross-tenant record write via direct ID | ASVS 4.2 | Manual | Burp Suite | Tenant B user cannot modify Tenant A records |
| TENANT-03 | Cross-tenant user enumeration | ASVS 4.2 | Manual | Burp Suite | User list scoped to own tenant |
| TENANT-04 | TDAL bypass via raw query path | QS-5 | White-box | Code review | No raw db.query() calls outside TDAL in production code |
| TENANT-05 | RLS bypass via SET LOCAL manipulation | QS-6 | Manual | Burp Suite + psql | RLS cannot be bypassed via application-layer header or parameter |
| TENANT-06 | Tenant ID spoofing in JWT claims | ASVS 3.5 | Manual | Burp Suite | Modified tenantId in JWT rejected |
| TENANT-07 | Cross-tenant data in aggregated reports | Domain-specific | Manual | Burp Suite | Reports return only own-tenant data |
| TENANT-08 | Platform admin cross-tenant data read | Domain-specific | Manual | Burp Suite | Platform admin operations do not expose tenant business data |

### 9.4 Audit Trail Integrity (AUDIT series)

| Test ID | Title | ASVS Ref / Reg | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| AUDIT-01 | Audit trail completeness — every mutation logged | 21 CFR 11.10(e), QS-1 | White-box + runtime | Code review + Burp | All INSERT/UPDATE/DELETE operations produce audit_trail entries |
| AUDIT-02 | Audit trail chain integrity — hash verification | 21 CFR 11.10(e), ALCOA+ | White-box + runtime | Custom script | Chain verification detects any modification to audit_trail rows |
| AUDIT-03 | Audit trail chain integrity — cross-tenant transplant | KD-002 specific | White-box + runtime | Custom script | Chain from Tenant A cannot be accepted as valid for Tenant B |
| AUDIT-04 | Audit trail immutability — application-layer delete | 21 CFR 11.10(e) | Manual | Burp Suite | No API endpoint permits deletion of audit_trail records |
| AUDIT-05 | Audit trail immutability — application-layer update | 21 CFR 11.10(e) | Manual | Burp Suite | No API endpoint permits modification of audit_trail records |
| AUDIT-06 | Before/after state in UPDATE audit entries | QS-1 | Runtime | Burp Suite | Update events contain field-level diff (before and after values) |
| AUDIT-07 | Audit attribution — userId never null | QS-2 | Runtime | Burp Suite | Every audit_trail entry has non-null userId and tenantId |

### 9.5 E-Signature Workflows (ESIG series)

| Test ID | Title | ASVS Ref / Reg | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| ESIG-01 | E-signature bypass — direct record state transition | 21 CFR 11.50 | Manual | Burp Suite | Direct API call to approved state without e-sig rejected |
| ESIG-02 | E-signature replay — reuse previously captured signing token | 21 CFR 11.50 | Manual | Burp Suite | Signing tokens are single-use; replay rejected |
| ESIG-03 | E-signature meaning — meaning of signing logged | 21 CFR 11.50 | Runtime | Burp Suite | Audit entry includes signing meaning (e.g., "Approved by Quality Lead") |
| ESIG-04 | E-signature attribution — signed by authenticated user | 21 CFR 11.50 | Runtime | Burp Suite | Signature attributed to JWT-authenticated userId, not parameter-supplied |
| ESIG-05 | E-signature for AI output acceptance | QS-21, EU Annex 22 §7 | Manual | Burp Suite | AI suggestion acceptance requires e-sig; direct write without sig rejected |
| ESIG-06 | Password re-authentication for signing | 21 CFR 11.300 | Manual | Burp Suite | E-sig requiring password re-entry cannot be bypassed |
| ESIG-07 | Multi-step approval — skip step | Domain-specific | Manual | Burp Suite | Cannot bypass intermediate approval step |
| ESIG-08 | Delegation — sign on behalf without authorization | Domain-specific | Manual | Burp Suite | Signing delegation requires authorized delegation record |
| ESIG-09a | Concurrent signing — race condition on approval | Domain-specific | Manual | Burp Suite + Turbo Intruder | Concurrent approval requests resolve to single approval with no ghost approvals |
| ESIG-09b | Concurrent signing — token reuse between sessions | Domain-specific | Manual | Burp Suite | Concurrent e-sig sessions cannot reuse each other's signing tokens. **Go-Live Gate G-8 requires retest evidence on file.** |
| ESIG-10 | E-signature audit trail completeness | 21 CFR 11.10(e) | Runtime | Burp Suite | Every e-signature event logged with userId, timestamp, meaning, and record reference |

### 9.6 Impersonation and Session (IMP series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| IMP-01 | Session hijacking via token theft simulation | ASVS 3.4 | Manual | Burp Suite | Token binding or detection in place |
| IMP-02 | Admin impersonation — audit attribution | QS-2, 21 CFR 11.50 | Manual | Burp Suite | Actions during admin impersonation attributed to impersonator, not subject user. **Go-Live Gate G-7.** |
| IMP-03 | Support impersonation — audit attribution | QS-2, 21 CFR 11.50 | Manual | Burp Suite | Subject user identity noted in audit; impersonator attributed. **Go-Live Gate G-7.** |
| IMP-04 | Concurrent session limits | ASVS 3.3 | Manual | Burp Suite | Configured session limits enforced |
| IMP-05 | Session invalidation on logout | ASVS 3.3 | Manual | Burp Suite | Token invalidated server-side on logout |
| IMP-06 | Session invalidation on password change | ASVS 3.3 | Manual | Burp Suite | All other sessions invalidated on password change |

### 9.7 AI and ML Attack Surface (AI series)

| Test ID | Title | Regulatory Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| AI-01 | Prompt injection — data exfiltration via Mira | EU Annex 22, QS-21 | Manual | Burp Suite | Injection cannot exfiltrate records outside user's authorized scope |
| AI-02 | Prompt injection — cross-tenant data access | EU Annex 22, QS-21 | Manual | Burp Suite | Injection cannot access other tenant's records |
| AI-03 | Prompt injection — command injection to backend | EU Annex 22 | Manual | Burp Suite | No backend command execution via AI input |
| AI-04 | AI output written directly to GxP fields | QS-21, EU Annex 22 §7 | Manual | Burp Suite | Direct AI output write to regulated fields blocked; e-sig required |
| AI-05 | HITL gate bypass — force AI decision through without human review | QS-23, EU Annex 22 §7 | Manual | Burp Suite | HITL gate cannot be bypassed; AI decision pending human review cannot be auto-confirmed |
| AI-06 | Low-confidence AI decision auto-escalation | QS-23, hitl_gate_config | Runtime | Burp Suite | Low-confidence AI output triggers escalation to quality_lead |
| AI-07 | AI suggestion accepted without e-signature | QS-21, 21 CFR 11.50 | Manual | Burp Suite | AI suggestion acceptance requires e-sig; unsigned acceptance rejected |
| AI-08 | Model version logged in ai_requests / llm_audit_log | QS-21 | Runtime | Burp Suite | Every AI inference logged with model name and version |
| AI-09 | systemPrompt extraction via prompt injection | KD-003a | Manual | Burp Suite | System prompt content not extractable via user input. **Maps to KD-003a — finding pre-confirmed via code review. Test verifies scope completeness and confirms closure post-remediation. Do not mark as Pass until KD-003a CAPA is closed.** |
| AI-10 | overrideResult() — write to GxP field without e-sig | KD-003b | Manual | Burp Suite | overrideResult() requires e-sig confirmation; unsigned call rejected |
| AI-11 | overrideResult() — write to GxP field without HITL gate | KD-003b | White-box + Manual | Code review + Burp | HITL gate enforced before overrideResult() writes to regulated fields |
| AI-12 | overrideResult() — AI authorship in audit trail | KD-003b | Runtime | Burp Suite | Audit entry attributes final decision to human approver, not AI model |

### 9.8 Background Jobs (JOB series)

| Test ID | Title | Regulatory Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| JOB-01 | Unauthenticated access to job trigger endpoints | QS-7 | Manual | Burp Suite | All job endpoints return 401 for unauthenticated requests |
| JOB-02 | Under-privileged role access to job trigger endpoints | QS-7, KD-005 | Manual | Burp Suite | Non-platform_admin roles receive AUTHZ_ROLE_DENIED (not 404, not "no permission configuration") |
| JOB-03 | Platform_admin — only authorized jobs triggerable | QS-7 | Manual | Burp Suite | platform_admin cannot trigger jobs outside its authorized set |
| JOB-04 | **RBAC sweep of all 31 background job endpoints** | QS-7, KD-005 | Automated | **Custom Python + Logger++** | All 31 job endpoints return AUTHZ_ROLE_DENIED for non-platform_admin. Zero endpoints return "Route does not have permission configuration." Report must list all 31 endpoints tested with individual Pass/Fail per endpoint. |
| JOB-05 | Audit trail for mutating background jobs — each mutating job must produce audit_log entry with correct tenantId, userId (system account), action, timestamp | Runtime + psql | audit_log entry present for every mutating job execution; userId = system account, not null |
| JOB-06 | Tenant isolation for cross-tenant background jobs — jobs operating on tenant data must use TDAL context | Runtime + psql | No cross-tenant data leakage; each job operation scoped to correct tenant |
| JOB-07 | Queue payload validation — malformed/oversized queue payloads must be rejected gracefully | Automated + Manual | Malformed payloads return 400/422; no unhandled 500; no data corruption in target tables |

### 9.9 SSRF (SSRF series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| SSRF-01 | Webhook SSRF — RFC 1918 private IP ranges | KD-004, ASVS 10.3.2 | Manual | Burp Suite | Webhook registration with internal IP (10.x, 172.16-31.x, 192.168.x) rejected |
| SSRF-02 | Webhook SSRF — link-local address (169.254.x.x) | KD-004, ASVS 10.3.2 | Manual | Burp Suite | Webhook registration with 169.254.x.x addresses rejected |
| SSRF-03 | Webhook SSRF — regulatory feed URL (regulatory-impact.service) | KD-004, ASVS 10.3.2 | Manual | Burp Suite | Tenant-configured feed_url subject to same SSRF protections; internal targets blocked |

### 9.10 File Upload and Download (FILE series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| FILE-01 | Unrestricted file upload — malicious file type | ASVS 12.2 | Manual | Burp Suite | Non-whitelisted file types rejected |
| FILE-02 | Path traversal in file download | ASVS 12.3 | Manual | Burp Suite | Path traversal sequences rejected; files scoped to authorized bucket |
| FILE-03 | SSRF via file URL reference | ASVS 10.3 | Manual | Burp Suite | URL-based file references do not trigger SSRF |
| FILE-04 | Virus / malware scan bypass | ASVS 12.2 | Manual | Burp Suite | Known EICAR test file blocked |
| FILE-05 | Download authorization — cross-tenant file access | ASVS 4.2 | Manual | Burp Suite | Files scoped to own tenant; cross-tenant download rejected |

### 9.11 API Security (API series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| API-01 | Mass assignment — unintended field update | ASVS 13.1 | Manual | Burp Suite | Non-whitelisted fields in request body silently ignored or rejected |
| API-02 | HTTP verb tampering | ASVS 13.1 | Manual | Burp Suite | Unexpected HTTP verbs return 405 with correct Allow header |
| API-03 | Rate limiting on sensitive endpoints | ASVS 13.1 | Automated | Burp Intruder | Auth and high-value endpoints rate-limited |
| API-04 | GraphQL introspection disabled in production config | ASVS 13.4 | Manual | Burp Suite | Introspection returns error in staging-as-production-config |
| API-05 | GraphQL batching / query depth attack | ASVS 13.4 | Automated | InQL | Depth and complexity limits enforced |
| API-06 | Sensitive data in GET query parameters | ASVS 8.3 | Manual | Burp Suite | No tokens, PII, or sensitive IDs in GET parameters |
| API-07 | API versioning — old version still accessible | QS-18 | Manual | Burp Suite | Old API versions return deprecation response or are removed |
| API-08 | Error response information leakage | QS-9 | Manual | Burp Suite | No stack traces, SQL errors, column names in API error responses |

### 9.12 Injection (INJ series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| INJ-01 | SQL injection — primary application inputs | ASVS 5.3.4 | Automated + Manual | SQLMap + Burp | No SQL injection in any parameterized input |
| INJ-02 | SQL injection — search and filter endpoints | ASVS 5.3.4 | Automated | SQLMap | All search inputs parameterized |
| INJ-03 | LDAP injection (if LDAP integration present) | ASVS 5.3.7 | Manual | Burp Suite | LDAP inputs sanitized |
| INJ-04 | XML/XPath injection (if XML processing present) | ASVS 5.3.9 | Manual | Burp Suite | XML inputs sanitized |
| INJ-05 | Command injection via filename or parameter | ASVS 5.3.8 | Manual | Burp Suite | No OS command execution via user input |
| INJ-06 | Server-side template injection | ASVS 5.3 | Manual | Burp Suite | No SSTI in any template-rendered endpoint |

### 9.13 Cross-Site Scripting (XSS series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| XSS-01 | Reflected XSS — all input parameters | ASVS 5.3.3 | Automated + Manual | Burp Suite Active Scan | No reflected XSS |
| XSS-02 | Stored XSS — GxP record fields | ASVS 5.3.3 | Manual | Burp Suite | No stored XSS in any GxP record display field |
| XSS-03 | DOM-based XSS — client-side rendering | ASVS 5.3.3 | Manual | Burp Suite | No DOM XSS |
| XSS-04 | Content-Security-Policy enforcement | ASVS 5.3.3 | Manual | Browser DevTools | CSP header present; inline scripts blocked |

### 9.14 Secrets and Configuration Exposure (SEC series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| SEC-01 | Hardcoded credentials in source code | ASVS 14.2 | Automated | truffleHog, gitleaks | No secrets in code repository |
| SEC-02 | Secrets in environment variable exposure via API | ASVS 14.2 | Manual | Burp Suite | No env vars returned in API responses |
| SEC-03 | .env file accessible via web server | ASVS 14.2 | Manual | Burp Suite | .env and config files not served |
| SEC-04 | Cloud storage misconfiguration | ASVS 14.2 | Manual | aws-cli / gcloud | S3/GCS buckets not publicly accessible |
| SEC-05 | Secrets in logs | ASVS 14.2 | White-box | Code review + log review | No tokens, passwords, or API keys in log output |

### 9.15 Cloud Infrastructure (CLOUD series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| CLOUD-01 | IAM least privilege — service accounts | ASVS 14.4 | Config review | aws-cli / gcloud | No over-privileged service accounts |
| CLOUD-02 | Network exposure — unnecessary open ports | ASVS 14.4 | Automated | nmap | Only required ports open; no unnecessary exposure |
| CLOUD-03 | TLS configuration — cipher suite | ASVS 9.1 | Automated | testssl.sh | No weak ciphers; TLS 1.2 minimum; TLS 1.3 preferred |
| CLOUD-04 | CORS misconfiguration | ASVS 14.5 | Manual | Burp Suite | CORS not open to all origins; credentialed requests restricted |
| CLOUD-05 | SSRF via integration webhooks | ASVS 10.3 | Manual | Burp Suite | Webhook targets restricted; SSRF blocked |
| CLOUD-06 | Container escape / metadata service access | ASVS 14.4 | Manual | Burp Suite | Cloud metadata service not accessible via SSRF |

### 9.16 Integrations and Webhooks (INT series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| INT-01 | Webhook signature verification | ASVS 13.2 | Manual | Burp Suite | Unsigned or incorrectly signed webhooks rejected |
| INT-02 | Outbound request filtering | ASVS 10.3 | Manual | Burp Suite | Outbound requests from integrations restricted to allowlist |
| INT-03 | OAuth token scope creep | ASVS 3.5 | Manual | Burp Suite | OAuth tokens for integrations scoped to minimum required permissions |
| INT-04 | Third-party secret storage | ASVS 14.2 | White-box | Code review | Third-party API keys stored encrypted, not in plaintext columns |

### 9.17 CI/CD and Secrets Management (CICD series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| CICD-01 | Pipeline secrets not in logs | ASVS 14.2 | Log review | CI log review | No secrets in CI/CD pipeline output |
| CICD-02 | Pipeline trigger authorization | ASVS 14.4 | Config review | Config review | Pipeline triggers require authenticated authorization |
| CICD-03 | Dependency integrity — supply chain | ASVS 14.2 | Automated | Dependabot / SBOM | No known-vulnerable dependencies above Low severity |

### 9.18 Data Protection (DATA series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| DATA-01 | Encryption at rest — database | ASVS 8.3 | Config review | Cloud console | Database encrypted at rest |
| DATA-02 | Encryption in transit — all endpoints | ASVS 9.1 | Automated | testssl.sh | All endpoints served over TLS; no HTTP |
| DATA-03 | PII in API responses — data minimization | ASVS 8.3 | Manual | Burp Suite | API responses do not include unrequested PII fields |
| DATA-04 | Data export authorization | ASVS 4.1 | Manual | Burp Suite | Data export restricted to authorized roles; export logged in audit trail |

### 9.19 Frontend Security (FE series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| FE-01 | Security headers — CSP, HSTS, X-Frame-Options | ASVS 14.4 | Automated | Mozilla Observatory | Required security headers present and correctly configured |
| FE-02 | Clickjacking | ASVS 14.4 | Manual | Burp Suite | X-Frame-Options: DENY or CSP frame-ancestors restricts embedding |
| FE-03 | localStorage / sessionStorage — sensitive data | ASVS 8.3 | Manual | Browser DevTools | No tokens, secrets, or PII stored in browser storage |
| FE-04 | JavaScript source map exposure | ASVS 14.2 | Manual | Browser DevTools | Source maps not served in staging-as-production-config |

### 9.20 Input Validation (IV series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| IV-01 | Zod schema enforcement — boundary validation | QS-8 | Manual | Burp Suite | Invalid input shapes return 400 with field-level error |
| IV-02 | URL parameter validation | QS-8 | Manual | Burp Suite | Invalid URL params return 400, not 500 |
| IV-03 | Large payload / DoS via oversized input | ASVS 13.1 | Manual | Burp Suite | Payload size limits enforced |
| IV-04 | Unicode / encoding attack | ASVS 5.2 | Manual | Burp Suite | Unicode normalization attacks do not bypass validation |

### 9.21 Password and Credential Security (CRED series)

| Test ID | Title | ASVS Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| CRED-01 | Password hashing algorithm | ASVS 2.4 | White-box | Code review | Passwords hashed with bcrypt/Argon2/scrypt; no MD5/SHA-1 |
| CRED-02 | Credential stuffing protection | ASVS 2.2 | Automated | Burp Intruder | Rate limiting and account lockout protect against stuffing |
| CRED-03 | Weak password policy bypass | ASVS 2.1 | Manual | Burp Suite | Weak passwords rejected at API level, not frontend-only |

### 9.22 Business Logic (BL series)

| Test ID | Title | Method | Tool | Pass Criteria |
|---|---|---|---|---|
| BL-01 | Workflow state machine bypass | Manual | Burp Suite | Cannot transition records to invalid states via API |
| BL-02 | Batch operation integrity — partial failure rollback | Manual | Burp Suite | Failed batch operations rolled back; no partial writes |
| BL-03 | Concurrent modification — optimistic lock bypass | Manual | Burp Suite + Turbo Intruder | Concurrent writes to same record handled; no lost updates |
| BL-04 | Negative quantity / boundary value attacks | Manual | Burp Suite | Numeric fields reject out-of-range and negative values |

### 9.23 Compliance-Specific (COMP series)

| Test ID | Title | Regulatory Ref | Method | Tool | Pass Criteria |
|---|---|---|---|---|---|
| COMP-01 | Audit trail cannot be disabled by any user | 21 CFR 11.10(e) | Manual | Burp Suite | No API endpoint or user action disables audit logging |
| COMP-02 | Timestamps server-generated — cannot be client-supplied | QS-3, ALCOA+ | Manual | Burp Suite | Client-supplied timestamps rejected or ignored for GxP records |
| COMP-03 | Soft-delete enforced — hard delete blocked | QS-4 | Manual | Burp Suite | DELETE endpoints perform soft-delete; hard delete rejected |
| COMP-04 | Soft-deleted records accessible in audit queries | QS-4 | Manual | Burp Suite | Soft-deleted records included in audit export queries |
| COMP-05 | AI model version logged per inference | QS-21, QS-22 | Runtime | Burp Suite | llm_audit_log / ai_requests contains model name and version per inference |

---

## 10. Testing Cadence and Periodicity

### 10.1 Scheduled Testing

| Test Type | Frequency | Trigger | Notes |
|---|---|---|---|
| Full penetration test | Annual | Calendar — anniversary of last full test | All 22 test surfaces; all KD series |
| Pre-release test | Prior to each major release | Release candidate declaration | Scoped to changed surfaces + all Critical/High finding retests |
| Targeted retest | Within 7 days of Critical finding remediation | Critical finding closure claim | Confirms Critical finding resolved |
| Targeted retest | Within 30 days of High finding remediation | High finding closure claim | Confirms High finding resolved |

### 10.2 Event-Triggered Testing

In addition to scheduled testing, a targeted penetration test or security review is required when any of the following events occur:

| Trigger | Scope | SLA |
|---|---|---|
| Material architecture change (new service, new data tier, new authentication system) | Scoped to changed components + integration points | Before production deployment |
| **New AI model version deployed to production** | AI series test cases (AI-01 through AI-12); HITL gate verification | Before production deployment |
| **AI provider change (e.g., Anthropic to Azure OpenAI, or new model family)** | Full AI surface; AI series + HITL + audit logging | Before production deployment |
| **Prompt template change (any Mira or copilot prompt version bump)** | AI-09, AI-10, AI-11, AI-12; HITL bypass verification; audit trail logging | Before production deployment |
| New integration or third-party connector added | INT series + SSRF series + relevant AUTH/RBAC tests | Before production deployment |
| New regulatory requirement with security control implications | Compliance-specific test cases; COMP series | Within 60 days of regulatory effective date |
| Security incident suggesting exploitation of in-scope vulnerability | Full scope or targeted scope per incident analysis | Immediately following incident containment |
| Significant staff change in penetration testing team | Qualification review per Section 13 | Before next engagement |

---

## 11. Execution Phases

This engagement is structured as **10 phases (Phase 0 through Phase 9)**. The phase model was corrected in v8.1 from an earlier erroneous reference to "7 phases." All phase numbering and naming below is canonical.

| Phase | Name | Duration | Key Output |
|---|---|---|---|
| Phase 0 | Pre-Engagement Setup | Week 1 (before Day 1) | Signed authorization, all 11 accounts provisioned, baseline counts |
| Phase 1 | Reconnaissance and Surface Mapping | Days 1–3 | Site map, open ports, TLS report, route baseline |
| Phase 2 | Authentication and Session Testing | Days 3–5 | AUTH/IMP/ESIG/CRED findings |
| Phase 3 | Authorization and Tenant Isolation | Days 5–10 | RBAC/TENANT/BL findings |
| Phase 4 | Injection and Input Validation | Days 8–12 | INJ/XSS/IV findings |
| Phase 5 | Audit Trail and GxP Compliance | Days 10–14 | AUDIT/COMP/white-box findings |
| Phase 6 | AI/ML and Background Job Testing | Days 12–16 | AI/JOB/SSRF/API findings |
| Phase 7 | Infrastructure, Secrets, Configuration | Days 14–18 | SEC/CLOUD/INT/CICD/DATA/FE findings |
| Phase 8 | Known Defect Exploitation Attempts | Days 16–20 | KD-001, KD-002, KD-003a, KD-003b, KD-004, KD-005 exploitation confirmation |
| Phase 9 | Reporting and Knowledge Transfer | Days 20–26 | D-1 through D-7 deliverables, go-live gate assessment |

### Phase 0 — Pre-Engagement Setup

All items must be complete before Phase 1 begins.

| # | Activity | Owner | Status |
|---|---|---|---|
| P0-01 | Authorization document fully executed (Section 3.1) | Security Lead | [REQUIRED BEFORE SIGN-OFF] |
| P0-02 | Staging environment confirmed equivalent to production | Platform Engineering | [REQUIRED BEFORE SIGN-OFF] |
| P0-03 | Test accounts provisioned and credentials delivered — all 11 accounts (Section 4.2) | Platform Engineering | [REQUIRED BEFORE SIGN-OFF] |
| P0-04 | Emergency contact confirmed reachable | Security Lead | [REQUIRED BEFORE SIGN-OFF] |
| P0-05 | Tester qualifications and independence declarations on file | Security Lead | [REQUIRED BEFORE SIGN-OFF] |
| P0-06 | Known Open Defects (Section 8) briefed to tester — all 6 KDs confirmed | Security Lead | [REQUIRED BEFORE SIGN-OFF] |
| P0-07 | Evidence storage solution configured and encrypted | Tester | [REQUIRED BEFORE SIGN-OFF] |
| P0-08 | Verixa monitoring team notified of test window | Security Lead | [REQUIRED BEFORE SIGN-OFF] |
| P0-09 | Current commit hash documented (staging deployment) | Platform Engineering | [REQUIRED BEFORE SIGN-OFF: commit hash: ____________] |
| P0-10 | **Automated route-permission scan complete — total route count documented as baseline for RBAC-15 sweep** | Security Lead | [REQUIRED BEFORE SIGN-OFF: total route count: ____________] |
| P0-11 | **4 failing authority profile IDs documented and recorded in KD-001 precondition field** | Security Lead | [REQUIRED BEFORE SIGN-OFF: Profile 1 ID: ___ Profile 2 ID: ___ Profile 3 ID: ___ Profile 4 ID: ___] |

### Phase 1 — Reconnaissance and Surface Mapping

- Enumerate all API endpoints using authenticated and unauthenticated sessions.
- Map application routes against documented route list; identify undocumented routes.
- Enumerate all authentication endpoints and mechanisms.
- Review OpenAPI/Swagger documentation if available; flag discrepancies.
- Identify all file upload/download surfaces.
- Identify all AI/ML interaction surfaces.
- Identify all background job trigger endpoints; confirm count against PRE-12 baseline.
- Identify all webhook and integration connector surfaces (SSRF attack surface for KD-004).

### Phase 2 — Authentication and Session Testing

Execute: AUTH series (AUTH-01 through AUTH-10, AUTH-P-07), IMP series (IMP-01 through IMP-06), ESIG series (ESIG-01 through ESIG-10), CRED series (CRED-01 through CRED-03).

### Phase 3 — Authorization and Tenant Isolation Testing

Execute: RBAC series (RBAC-01 through RBAC-15), TENANT series (TENANT-01 through TENANT-08), BL series (BL-01 through BL-04).

### Phase 4 — Injection and Input Validation Testing

Execute: INJ series (INJ-01 through INJ-06), XSS series (XSS-01 through XSS-04), IV series (IV-01 through IV-04).

### Phase 5 — Audit Trail and GxP Compliance Testing

Execute: AUDIT series (AUDIT-01 through AUDIT-07), COMP series (COMP-01 through COMP-05), white-box review per Section 12.

### Phase 6 — AI/ML, Background Job, and SSRF Testing

Execute: AI series (AI-01 through AI-12), JOB series (JOB-01 through JOB-07), SSRF series (SSRF-01 through SSRF-03), API series (API-01 through API-08).

### Phase 7 — Infrastructure, Secrets, and Configuration Testing

Execute: SEC series (SEC-01 through SEC-05), CLOUD series (CLOUD-01 through CLOUD-06), INT series (INT-01 through INT-04), CICD series (CICD-01 through CICD-03), DATA series (DATA-01 through DATA-04), FE series (FE-01 through FE-04).

### Phase 8 — Known Defect Exploitation Attempts

- Targeted exploitation attempts for all KD-series findings: KD-001, KD-002, KD-003a, KD-003b, KD-004, KD-005.
- Document whether each KD finding is exploitable as discovered, partially exploitable, or not exploitable in the deployed environment.
- Results feed directly into PENTEST findings register (see Appendix B).
- KD-001 PRECONDITION: 4 failing profile IDs must have been recorded in Phase 0 (P0-11) before AUTH-P-07 can be executed.
- KD-004 SSRF tests (SSRF-01, SSRF-02, SSRF-03) must be executed against both webhook-connector.ts and regulatory-impact.service.ts surfaces.

### Phase 9 — Reporting and Knowledge Transfer

- Draft findings report delivered to Security Lead for review.
- Finding severity disputes resolved through defined process (see Section 6.1).
- Final report issued.
- Go-Live Gate assessment completed for all 9 gates (G-1 through G-9) per Section 5.3.
- Knowledge transfer session with Verixa engineering team.

---

## 12. White-Box Review Targets

The following code areas must be reviewed as part of the white-box component of the engagement:

| Area | Relevant Files / Modules | Review Objective |
|---|---|---|
| Audit trail chain implementation | `auditTrailService.*`, `audit_trail` table schema and trigger | Verify chain algorithm, key material, TenantId inclusion (KD-002) |
| Authority profile gate evaluation | AUTHZ-006 rule evaluation engine; authority profile configuration | Verify 4 identified profiles evaluate gate conditions correctly (KD-001) |
| TDAL implementation | `tdal.*`, `withTenant()` function | Verify no raw query bypass |
| RLS policies | All migration files containing `ENABLE ROW LEVEL SECURITY` | Verify all tables have correct policies |
| overrideResult() function | AI module — result override pathway | Verify e-sig gate and HITL enforcement (KD-003b) |
| systemPrompt handling | Mira copilot service | Verify prompt injection mitigations (KD-003a) |
| Background job RBAC guards | All 31 job endpoint route handlers | Verify `requirePermission()` presence (KD-005) |
| Webhook URL validation | `webhook-connector.ts:45`; `regulatory-impact.service.ts:511` | Verify IP blocklist, hostname blocklist, DNS rebinding protection (KD-004) |
| E-signature HITL gate | `hitl_decisions`, `hitl_gate_config` tables and service | Verify critical AI decisions require human confirmation |
| Zod input validation | All route handlers and service boundaries | Verify QS-8 compliance |

---

## 13. Tester Qualification and Independence

### 13.1 Required Qualifications

At least one tester on the engagement must hold one or more of the following:

- OSCP (Offensive Security Certified Professional)
- GPEN (GIAC Penetration Tester)
- GWAPT (GIAC Web Application Penetration Tester)
- CREST CRT or CCT-APP
- CEH (Certified Ethical Hacker) — acceptable as supplementary qualification only

For regulated GxP engagements, at least one tester must demonstrate familiarity with 21 CFR Part 11 and EU Annex 11 requirements as they apply to electronic records and signatures. This may be demonstrated via a written attestation reviewed by the Security Lead, or by demonstrated prior regulated-system pentest experience.

### 13.2 Independence Requirements

- No tester may have been employed by or contracted to Verixa in the 12 months prior to the engagement.
- No tester may have contributed code to any Verixa repository in the 24 months prior to the engagement.
- Each tester must sign an independence declaration before testing begins.
- Independence declarations must be filed with the engagement authorization package.

### 13.3 Qualification Evidence on File

| Tester Name | Certifications | Independence Declaration | Filed Date |
|---|---|---|---|
| [REQUIRED BEFORE SIGN-OFF: Tester name] | [REQUIRED BEFORE SIGN-OFF: Certifications held] | [REQUIRED BEFORE SIGN-OFF: Declaration signed and on file — Yes / No] | [REQUIRED BEFORE SIGN-OFF: Date filed] |

---

## 14. Tool Inventory

| Tool | Version | Purpose | Authorized for Use? |
|---|---|---|---|
| Burp Suite Professional | [REQUIRED BEFORE SIGN-OFF: version used during engagement] | Web application interception, scanning, active testing | Yes |
| Burp Suite Turbo Intruder | Current with Burp | Concurrent request testing (ESIG-09a, ESIG-09b, BL-03) | Yes |
| OWASP ZAP | [REQUIRED BEFORE SIGN-OFF: version] | Supplementary automated scanning | Yes |
| SQLMap | [REQUIRED BEFORE SIGN-OFF: version] | SQL injection detection (INJ-01, INJ-02) | Yes |
| jwt_tool | Current | JWT attack testing (AUTH-01 through AUTH-04) | Yes |
| testssl.sh | Current | TLS configuration analysis (CLOUD-03, DATA-02) | Yes |
| nmap | Current | Network port scanning (CLOUD-02) | Yes — staging only |
| truffleHog | Current | Secret scanning in repositories (SEC-01) | Yes |
| gitleaks | Current | Secret scanning in git history (SEC-01) | Yes |
| InQL | Current | GraphQL security testing (API-04, API-05) | Yes |
| Mozilla Observatory | Current | Security header analysis (FE-01) | Yes |
| Custom Python scripts | [REQUIRED BEFORE SIGN-OFF: describe and version any custom scripts used] | Audit trail chain verification (AUDIT-02, AUDIT-03); JOB-04 RBAC sweep; SSRF-01/SSRF-02/SSRF-03 webhook validation | Yes — must be reviewed by Verixa Security Lead before use |
| Logger++ (Burp extension) | Current | Enhanced request logging for JOB-04 sweep | Yes |

**Tool authorization note:** Any tool not listed above requires written approval from the Security Lead before use. New tools added after engagement start must be documented as a scope change.

---

## 15. Pre-Engagement Confirmed Vulnerabilities

The following vulnerabilities are confirmed by internal code review and are pre-registered as findings. The penetration test must attempt to demonstrate exploitability in the deployed environment and must retest post-remediation.

| ID | Finding Title | Pre-Test Severity | Pentest Finding ID | Retest Required | Status |
|---|---|---|---|---|---|
| KD-001 | 4 authority profiles gate incorrectly — profiles allow actions they are configured to prevent | High | PENTEST-001 | Yes | Open |
| KD-002 | Audit trail chain: unkeyed SHA-256, TenantId excluded | **Critical** | PENTEST-002 | Yes — G-1 + G-5 | Open |
| KD-003a | AI gateway user-supplied systemPrompt; all 10 prompt injection tests describe.skip | High | PENTEST-003 | Yes | Open |
| KD-003b | overrideResult() writes LLM output to GxP fields without e-sig / HITL gate | **Critical** | PENTEST-004 | Yes — G-1 + G-6 + G-9 | Open |
| KD-004 | Webhook SSRF: user-supplied webhook_url, only format validation, no IP/hostname blocklist | High | PENTEST-005 | Yes | Open |
| KD-005 | Background job RBAC: suspected missing guards on 31 job endpoints | High | PENTEST-006 | Yes | Open |

**Important:** KD-002 and KD-003b are Critical severity. Under Go-Live Gate G-1, zero Critical findings may be open at production release. These findings independently block go-live regardless of any other gate status.

**Important:** KD-001, KD-003a, KD-004, and KD-005 are High severity. Under Go-Live Gate G-2, zero High findings may be open at go-live except with explicit QA-signed risk acceptance per finding, and only for non-GxP-impacting surfaces. KD-001 (RBAC/access control), KD-003a (AI/ML), KD-004 (SSRF/integration connectors), and KD-005 (background job RBAC) all touch GxP surfaces. QA risk acceptance for these findings does not eliminate the blocking condition under G-2.

---

## 16. Appendix A — Regulatory Mapping

| Finding Category | 21 CFR Part 11 | EU Annex 11 | Other |
|---|---|---|---|
| Audit trail integrity | §11.10(e) | §9 | ALCOA+ Original |
| E-signature bypass | §11.50, §11.70 | §9, §14 | |
| Authentication / session | §11.10(d), §11.300 | §12 | |
| Access control / RBAC | §11.10(d) | §12 | ISO 27002 A.9 |
| AI output without human oversight | §11.50 (attribution) | EU Annex 22 §7 | EU AI Act Art. 14; QS-21; QS-23 |
| Tenant isolation | §11.10(d) | §12 | GDPR Art. 32 |
| Input validation | §11.10(a) | §4 | QS-8 |
| SSRF / outbound request forgery | N/A direct | §12 | OWASP API8:2023; ASVS V10.3.2 |
| Background job RBAC | §11.10(d) | §12 | QS-7 |

---

## 17. Appendix B — Execution Document

### B.1 Findings Register

All findings discovered during the engagement are recorded in this register. Pre-registered KD findings are seeded below as PENTEST-001 through PENTEST-006. New findings discovered during testing are added as PENTEST-007 onward.

| Finding ID | Title | Severity | Status | Asset | CAPA Reference | Evidence Package Ref | Evidence SHA-256 | Retest Status | Retest Date | Closed By | Close Date |
|---|---|---|---|---|---|---|---|---|---|---|---|
| PENTEST-001 | 4 authority profiles gate incorrectly (KD-001) | High | Open | Authority Profile module — AUTHZ-006 | [REQUIRED BEFORE SIGN-OFF: CAPA reference number] | [REQUIRED BEFORE SIGN-OFF: evidence archive filename] | [REQUIRED BEFORE SIGN-OFF: SHA-256 hash of evidence archive] | Not started | — | — | — |
| PENTEST-002 | Audit trail chain: unkeyed SHA-256, TenantId excluded (KD-002) | **Critical** | Open | audit_trail service | [REQUIRED BEFORE SIGN-OFF: CAPA reference number] | [REQUIRED BEFORE SIGN-OFF: evidence archive filename] | [REQUIRED BEFORE SIGN-OFF: SHA-256 hash of evidence archive] | Not started | — | — | — |
| PENTEST-003 | AI gateway systemPrompt; all 10 prompt injection tests describe.skip (KD-003a) | High | Open | Mira copilot service | [REQUIRED BEFORE SIGN-OFF: CAPA reference number] | [REQUIRED BEFORE SIGN-OFF: evidence archive filename] | [REQUIRED BEFORE SIGN-OFF: SHA-256 hash of evidence archive] | Not started | — | — | — |
| PENTEST-004 | overrideResult() writes LLM output to GxP fields without e-sig / HITL gate (KD-003b) | **Critical** | Open | AI module — overrideResult() | [REQUIRED BEFORE SIGN-OFF: CAPA reference number] | [REQUIRED BEFORE SIGN-OFF: evidence archive filename] | [REQUIRED BEFORE SIGN-OFF: SHA-256 hash of evidence archive] | Not started | — | — | — |
| PENTEST-005 | Webhook SSRF: user-supplied webhook_url, only format validation, no IP/hostname blocklist (KD-004) | High | Open | webhook-connector.ts; regulatory-impact.service.ts | [REQUIRED BEFORE SIGN-OFF: CAPA reference number] | [REQUIRED BEFORE SIGN-OFF: evidence archive filename] | [REQUIRED BEFORE SIGN-OFF: SHA-256 hash of evidence archive] | Not started | — | — | — |
| PENTEST-006 | Background job RBAC: suspected missing guards on 31 job endpoints (KD-005) | High | Open | packages/backend/src/jobs/ — all 31 endpoints | [REQUIRED BEFORE SIGN-OFF: CAPA reference number] | [REQUIRED BEFORE SIGN-OFF: evidence archive filename] | [REQUIRED BEFORE SIGN-OFF: SHA-256 hash of evidence archive] | Not started | — | — | — |

> **Evidence collection standard for this register:** Every evidence package must include: (a) original screenshot or request/response capture; (b) tester name and date; (c) engagement reference (VRX-SEC-PENTEST-001); (d) staging environment URL and confirmed environment identity (commit hash from P0-09); (e) SHA-256 hash of the complete evidence archive. The SHA-256 hash must be recorded in this register before the finding is submitted to the Security Lead for review. No finding may be escalated or closed without the SHA-256 hash on record.

### B.2 Deliverables Register (D-1 through D-7)

| Deliverable ID | Title | Description | Format | Owner | Due Date | Status |
|---|---|---|---|---|---|---|
| D-1 | Pre-Engagement Authorization Package | Signed authorization (Section 3.1), NDA, SOW, tester qualifications, independence declarations, test accounts confirmation (all 11 accounts per Section 4.2), PRE-12 baseline route count, P0-11 4 failing profile IDs | PDF, signed | Security Lead | [REQUIRED BEFORE SIGN-OFF: due date — must be complete before Phase 1 start] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |
| D-2 | Phase 0 Completion Certificate | Confirmation all PRE-01 through PRE-12 checklist items complete, including RBAC-15 baseline route count and P0-11 profile IDs; signed by Security Lead and Platform Engineering | Signed document | Security Lead | [REQUIRED BEFORE SIGN-OFF: due date — day of Phase 1 start] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |
| D-3 | Interim Findings Report | Mid-engagement findings summary for any Critical or High findings discovered, allowing remediation to begin before final report; includes Finding ID, severity, asset, brief description, and CAPA reference | Markdown or PDF | Tester | [REQUIRED BEFORE SIGN-OFF: due date — end of Phase 5 OR upon discovery of first Critical finding, whichever is earlier] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |
| D-4 | Draft Final Pentest Report | Complete findings register (all phases), severity ratings, evidence references, SHA-256 hashes, ASVS/regulatory control mappings, reproduction steps, remediation recommendations | PDF | Tester | [REQUIRED BEFORE SIGN-OFF: due date — within 5 business days of Phase 9 start] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |
| D-5 | Final Accepted Pentest Report | D-4 with Security Lead review comments resolved; finding severity disputes documented and resolved; final finding count per severity level | PDF, version-controlled | Tester + Security Lead | [REQUIRED BEFORE SIGN-OFF: due date — within 10 business days of Phase 9 start] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |
| D-6 | Go-Live Gate Assessment | Formal assessment against all 9 gates (G-1 through G-9) with Pass/Blocked determination per gate; supporting evidence reference per gate; Security Lead signature | Signed PDF | Security Lead | [REQUIRED BEFORE SIGN-OFF: due date — immediately following D-5 acceptance] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |
| D-7 | Evidence Archive | Complete evidence package for all findings (screenshots, request/response logs, tool outputs); SHA-256 hashes verified against Findings Register; encrypted per Section 3.1 and transferred to Verixa | Encrypted archive | Tester | [REQUIRED BEFORE SIGN-OFF: due date — same day as D-5 delivery] | [REQUIRED BEFORE SIGN-OFF: Not Started / In Progress / Complete] |

### B.3 Evidence Collection Standard

All evidence collected during this engagement must conform to the following standard:

1. **Capture at time of finding.** Evidence must be captured contemporaneously. No reconstruction or recreation after the fact.
2. **Label immediately.** Every artifact must be labeled with: tester name/ID, date (UTC), time (UTC), engagement reference (VRX-SEC-PENTEST-001), test case ID (e.g., AUDIT-02), and finding ID (e.g., PENTEST-002) once assigned.
3. **Complete captures.** Full HTTP request and full HTTP response must be captured for API findings. Partial captures require written justification in the finding report.
4. **SHA-256 hash required.** The complete evidence package for each finding (all files, screenshots, and captures bundled as a named archive) must have its SHA-256 hash computed and recorded in the Findings Register (Appendix B.1) before submission to the Security Lead. The hash must be computed before any transfer or copy of the archive.
5. **Encrypted storage.** Evidence archives must be encrypted per the standard specified in Section 3.1 at all times. Evidence must not be stored in unencrypted form outside a secure test workstation.
6. **Chain of custody.** Evidence transfer to Verixa must be logged: transfer date, transfer method, recipient name, and confirmation of receipt with SHA-256 hash verification.
7. **Retention.** Evidence retained for the period specified in Section 3.1. Destruction at end of retention period must be confirmed in writing to the Security Lead.

### B.4 Out-of-Scope Confirmation

The following are explicitly confirmed as out of scope for this engagement (cross-reference Section 1.4):

- Production environment
- Social engineering, phishing, physical access
- Denial-of-service
- Stealth/persistence
- Customer tenant data
- Third-party LLM provider infrastructure
- **Design-partner infrastructure** — any infrastructure owned or operated by Verixa design partners is excluded
- **Backup restoration validation** — this is a separate activity governed by Annex 11 §7 and §10 and must be scheduled as an independent controlled activity with separate authorization, test accounts, execution window, and evidence package
- Malware deployment, credential exfiltration, lateral movement

Any tester who identifies a potential finding that appears to require testing out-of-scope assets must immediately halt that line of testing, document the observation, and notify the Security Lead before proceeding.

---

## 18. Appendix C — Test Case Count Reconciliation

**v7 original claim:** 180 test cases across 22 attack surfaces.

**v8.0 grep-counted unique test IDs:** approximately 153.

**v8.1 status:** Full inventory reconciliation pending.

This plan covers 153 numbered test case IDs across 22 attack surfaces (pending full inventory reconciliation). The discrepancy between the v7 claimed 180 and the grep-counted 153 has not been fully explained. The v8.0 author could not locate 27 test IDs from the v7 count.

**[REQUIRED BEFORE SIGN-OFF: Security Lead to complete test inventory matrix (one row per test ID, series, surface, phase assignment, tool, pass criteria). Final count must be documented here and must match the count in the HTML execution guide and the findings register row allocation. Until reconciliation is complete, use "153 numbered test case IDs across 22 attack surfaces (pending full inventory reconciliation — Appendix C)" in all summary statements. Do NOT claim 180 without a verified test inventory matrix.]**

---

---

## 19. Appendix D — ASVS v4.0.3 to v5.0.0 Version Risk Assessment

**Purpose:** Formal governance record for the decision to use OWASP ASVS v4.0.3 in a June 2026 engagement. Required because ASVS v5.0 was released May 30, 2025 and a reviewer may challenge use of the older version.

### D.1 Known Control Gaps (v4.0.3 vs v5.0.0)

| Control Area | ASVS v4.0.3 Coverage | ASVS v5.0.0 Change | Compensating Test in This Plan |
|---|---|---|---|
| OAuth 2.0 / OIDC flows | V2.5 (limited) | Expanded dedicated OAuth chapter | AUTH-14 (OIDC nonce), AUTH-15 (SAML wrapping), supplemental OIDC tests via OWASP API Top 10 |
| API security | V13 (basic) | Replaced by API-specific chapter aligned to OWASP API Top 10 2023 | Full OWASP API Security Top 10 (2023) coverage in API series and INT series |
| LLM / AI attack surface | Not present | Not present (handled by OWASP LLM Top 10) | OWASP LLM Top 10 (2025) — AI series (AI-01 through AI-12) |
| Verification level restructure | Levels 1/2/3 | Redesigned level model | Test cases mapped to v4.0.3 levels; any v5.0 level-mapping gaps accepted as residual risk pending next retest |
| Cryptography controls | V6 | Updated cipher/algorithm guidance | CRYPT-01 through CRYPT-08, plus supplemental TLS audit via testssl.sh |
| WebSocket security | Limited | Expanded | WS-01 through WS-05 supplemental test cases |

### D.2 Residual Risk Acceptance

Unmapped ASVS v5.0 controls not compensated above are accepted as **Low residual risk** for this engagement on the following basis:
- The Verixa technology stack (Fastify, PostgreSQL, React, JWT, TOTP) has not materially changed since v4.0.3 was validated
- OWASP API Security Top 10 (2023) and LLM Top 10 (2025) supplement the gaps most relevant to Verixa's architecture
- The full v5.0 migration at next annual retest will close any remaining gap

**Risk acceptance owner:** [REQUIRED BEFORE SIGN-OFF: name and title of Security Lead or QA Head accepting residual risk]
**Risk acceptance date:** [REQUIRED BEFORE SIGN-OFF: date of formal acceptance]

### D.3 Migration Commitment

| Commitment | Target Date | Owner |
|---|---|---|
| ASVS v5.0.0 gap analysis vs. this plan completed | [REQUIRED: at least 60 days before next retest kick-off] | Security Lead |
| All v5.0 unmapped controls triaged (adopt / compensate / accept) | [REQUIRED: at least 30 days before next retest kick-off] | Security Lead + QA Head |
| Next engagement executed against ASVS v5.0.0 | [REQUIRED: annual retest target date] | Tester Lead |
| This appendix updated with migration evidence | [REQUIRED: same date as next retest kick-off] | Document Owner |

---

*End of Document*

**Document ID:** VRX-SEC-PENTEST-001 | **Version:** v8.1 | **Date:** June 2026
**Classification:** CONFIDENTIAL — Security Sensitive
**Next Scheduled Review:** [REQUIRED BEFORE SIGN-OFF: date of next annual review or next retest kick-off planning session]
**Document Owner:** [REQUIRED BEFORE SIGN-OFF: full name and title of document owner]
**Approved By:** [REQUIRED BEFORE SIGN-OFF: name, title, signature, and date of approving authority]