# Verixa Pentest Plan v7.0 — Security Review Feedback

| Field | Value |
|---|---|
| **Document Title** | Security Review Feedback: Verixa Penetration Test Plan v7.0 and Execution Document |
| **Feedback Document Version** | v1.0 |
| **Review Date** | 2026-06-05 |
| **Documents Reviewed** | Verixa Pentest Plan v7.0; Verixa Pentest Execution Document (companion .md) |
| **Reviewers** | Authorized Penetration Test Lead; API Security Tester; GxP Part 11 / Annex 11 Security Control Expert |
| **Classification** | CONFIDENTIAL — Security Sensitive — Restricted to Verixa Security and Quality Teams |
| **Target Go-Live Gate** | 01-Sep-2026 (Phase-2 Production) |
| **Review Status** | BLOCKED — Pre-Engagement Conditions Not Met (see Section 7) |

---

## Table of Contents

1. Executive Summary
2. Severity Summary Table
3. Section-by-Section Findings (RF-001 through RF-024)
4. GxP Security Control Review Table
5. API Security Coverage Assessment
6. Go-Live Gate Review
7. Pre-Engagement Blockers
8. Positive Findings
9. Appendix: Skill Frameworks Applied

---

## 1. Executive Summary

The Verixa Pentest Plan v7.0 represents a substantive and well-structured security assurance effort for a GAMP 5 Category 5 regulated AI eQMS platform. The 180-test-case scope, dual CVSS v3.1 plus Patient/Data-Integrity severity model, and cross-standard alignment with OWASP ASVS v4.0.3, NIST SP 800-115, 21 CFR Part 11, EU Annex 11, and Draft EU Annex 22 (2025) reflect genuine regulatory awareness. However, the plan cannot advance to Phase 0 execution in its current state: four pre-confirmed defects (KD-001 through KD-004) remain without raised CAPAs, two of them (KD-002 and KD-003) are under-rated relative to their actual regulatory and patient-safety impact, and the authorization section (Section 3.1) contains unfilled placeholder fields that legally prevent countersignature and constitute a rules-of-engagement gap under NIST SP 800-115. A total of 24 review findings (RF-001 through RF-024) are raised below, of which 5 are rated Critical, 10 High, 6 Medium, and 3 Low. Seven findings require resolution before Phase 0 can begin; two require go-live gate additions; and two known defects require immediate severity reclassification.

---

## 2. Severity Summary Table

| Severity | Total Findings | Require Pre-Engagement Resolution | Require Go-Live Gate Addition | Require Severity Upgrade on Existing KD |
|---|---|---|---|---|
| **Critical** | 5 | 3 | 2 | 2 (KD-002, KD-003B) |
| **High** | 10 | 3 | 0 | 0 |
| **Medium** | 6 | 1 | 0 | 0 |
| **Low** | 3 | 0 | 0 | 0 |
| **Total** | **24** | **7** | **2** | **2** |

> **Note on KD severity upgrades**: KD-002 and KD-003 are pre-confirmed defects already documented in the plan. This review recommends severity reclassification from High to Critical. These are not new findings raised by this review; they are severity corrections that have material go-live gate consequences (see RF-003 and RF-004 below, and Section 6).

---

## 3. Section-by-Section Findings

---

### RF-001 — Authorization Section Incomplete: Plan Cannot Be Countersigned

| Field | Detail |
|---|---|
| **Finding ID** | RF-001 |
| **Severity** | Critical |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Section 3.1 — Rules of Engagement / Authorization |
| **Status** | Pre-Engagement Blocker |

**Description**

Section 3.1 contains multiple unfilled `[INSERT: ...]` placeholder fields. Specifically, the test window dates, emergency contact name and contact number, and escalation tree names are absent. Under NIST SP 800-115 §3.1 (Planning Phase), a penetration test authorization document is not legally complete and cannot be acted upon without these fields. Countersignature cannot occur against a document with open placeholders. If testing proceeds without a countersigned authorization, it falls outside the legal safe-harbor for authorized security testing and creates liability exposure for both the test team and Verixa.

Additionally, in a GxP context, an incomplete authorization document cannot serve as the audit-trail record for why privileged test accounts were created, what actions were permitted, and who approved the test scope. This is an audit gap under 21 CFR Part 11 §11.10(e) (audit trail) and EU Annex 11 §12 (access control documentation).

**GxP / Regulatory Reference**

- NIST SP 800-115 §3.1 — Planning Phase: written authorization required
- 21 CFR Part 11 §11.10(e) — Audit trail attributability
- EU Annex 11 §12 — Access control and user role documentation

**Recommendation**

1. Populate all `[INSERT: ...]` fields in Section 3.1 before any further review or countersignature.
2. Establish a document freeze on the plan once countersigned — any subsequent scope changes require a formal amendment with re-countersignature.
3. Retain the countersigned authorization document in the Verixa QMS as a controlled security record.

---

### RF-002 — KD-001: Authority Profile Gate Failures — CAPA Not Raised, Profile IDs Unknown

| Field | Detail |
|---|---|
| **Finding ID** | RF-002 |
| **Severity** | Critical |
| **Skill Perspective** | Authorized Penetration Test Lead; GxP Part 11 / Annex 11 Expert |
| **Location in Document** | Section 14 (Known Defects); AUTH-P-07 (precondition); all four CAPA references showing `[CAPA-XXXX]` |
| **Status** | Pre-Engagement Blocker |

**Description**

KD-001 documents that four authority profiles gate incorrectly — a confirmed access control failure. This defect has three compounding problems:

1. **No CAPA raised**: All four CAPA references in the document appear as `[CAPA-XXXX]` placeholders. A confirmed access control failure in a regulated GxP system requires an immediate CAPA under 21 CFR Part 11 §11.10(d) and ICH Q10. The absence of a raised CAPA means there is no formal investigation owner, no root cause analysis, no remediation timeline, and no quality risk assessment on record.

2. **Profile IDs not identified**: The AUTH-P-07 precondition references the four failing profiles but their IDs are not populated. The test team cannot execute AUTH-P-07 without knowing which specific profiles are under test.

3. **Scope leakage risk**: If the four failing profiles are not identified before testing begins, the test team may inadvertently exercise these profiles during other test cases without the context that these are pre-confirmed failures, contaminating results and making it impossible to distinguish new findings from KD-001 manifestations.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.10(d) — Access control requirements
- EU Annex 11 §12 — Access control; validated roles and responsibilities
- ICH Q10 §3.2.2 — CAPA as mandatory quality system element
- 21 CFR Part 211.68 — Computer system access control in manufacturing quality

**Recommendation**

1. Raise four CAPA records in the QMS immediately (one per failing profile, or one parent CAPA with four child actions if the root cause is shared). Populate `[CAPA-XXXX]` references in the plan before countersignature.
2. Identify the four failing authority profile IDs and populate them in the AUTH-P-07 precondition.
3. Add a pre-testing note to all authorization-related test cases (AUTH-P-01 through AUTH-P-20) instructing testers to cross-reference KD-001 findings against the known profile IDs before logging a new finding.

---

### RF-003 — KD-002: Audit Trail Hash Severity Should Be Reclassified from High to Critical

| Field | Detail |
|---|---|
| **Finding ID** | RF-003 |
| **Severity** | Critical (reclassification of KD-002 currently rated High) |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert; Authorized Penetration Test Lead |
| **Location in Document** | Section 14, KD-002; Section 8 (Known Open Defects) |
| **Status** | Severity Correction Required; Pre-Engagement Blocker if reclassified |

**Description**

KD-002 documents that the audit trail hash implementation may use unkeyed SHA-256 rather than HMAC-SHA256, and that `tenantId` is absent from the hash payload. This is not a High finding. Under the GxP-plus-CVSS dual-dimension severity model stated in the plan itself, the patient/data-integrity impact dimension governs when it rates higher than CVSS. The correct classification is Critical for the following reasons:

1. **Record transplantation across tenants is possible**: Without `tenantId` in the hash payload, an audit record from Tenant A can be moved to Tenant B without hash invalidation. In a multi-tenant pharma SaaS, this means a regulated customer's audit trail could be contaminated with another customer's records, and the hash check would pass. This is not a theoretical attack — it is a trivially executable database operation with no cryptographic barrier.

2. **Unkeyed SHA-256 allows offline forgery**: Without a secret key, an attacker with write access to the database (via a compromised credential, insider threat, or SQL injection) can recompute a valid hash for a modified audit record. The audit trail's cryptographic integrity guarantee is nullified entirely.

3. **21 CFR Part 11 §11.10(e) compliance is broken**: The regulation requires audit trails to be accurate and not modifiable by users. If the hash can be recomputed without a key, the system cannot prove audit trail integrity during an FDA inspection. This is a 483 observation risk.

4. **EU Annex 11 §9 compliance is broken**: Annex 11 §9 requires that computerised systems protect audit trail data from modification. An unkeyed hash does not meet this requirement.

The current High rating allows this defect to be remediated on a standard timeline. A Critical rating triggers G-1 (no Critical findings open at go-live), requiring remediation and retest evidence before 01-Sep-2026 go-live.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.10(e) — Audit trail protection and accuracy
- EU Annex 11 §9 — Audit trail data protection
- OWASP ASVS v4.0.3 §V10.3 — Cryptographic key management
- NIST SP 800-115 — Evidence integrity requirements

**Recommendation**

1. Reclassify KD-002 to Critical in both Section 14 and Section 8 of the plan.
2. Raise a CAPA specifically for KD-002.
3. The remediation path is: (a) migrate hash function from SHA-256 to HMAC-SHA256 with a server-side secret key stored in the secrets manager; (b) add `tenantId` to the hash input payload; (c) re-hash all existing audit records under a documented migration procedure that is itself audited; (d) write regression tests for hash validation at service startup and on each audit record write.
4. Confirm in Phase 0 whether AUDIT-05 test coverage will include a positive test for HMAC-SHA256 verification failure on a tampered record.

---

### RF-004 — KD-003: AI Gateway `overrideResult()` Path Severity Should Be Reclassified from High to Critical

| Field | Detail |
|---|---|
| **Finding ID** | RF-004 |
| **Severity** | Critical (reclassification of KD-003B currently rated High under combined KD-003) |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert; API Security Tester |
| **Location in Document** | Section 14, KD-003; Section 8 (Known Open Defects); AI-09 test case |
| **Status** | Severity Correction Required; Pre-Engagement Blocker if reclassified |

**Description**

KD-003 documents two distinct vulnerabilities that are conflated under a single finding:

**Vulnerability A — Prompt Injection via Unsanitized `systemPrompt`**: The AI gateway accepts a user-supplied `systemPrompt` field with no sanitization. All 10 prompt injection test cases are marked `describe.skip`, meaning this attack surface is entirely untested in the current codebase. This is a direct violation of OWASP LLM Top 10 (2025) LLM01 (Prompt Injection) and should be High severity on its own.

**Vulnerability B — `overrideResult()` Direct Write to GxP Fields Without E-Signature**: The `overrideResult()` function writes arbitrary LLM-generated text directly to GxP record fields with no human-in-the-loop e-signature confirmation. The plan's own QS-21 standard (AI Output Segregation) explicitly prohibits writing LLM output directly to `complaints.root_cause`, `deviations.investigation_conclusion`, `capas.action_description`, `batch_records.disposition`, or any GxP-critical field without e-signature. This is not a theoretical risk — the code path is confirmed operational.

Vulnerability B alone is a Critical finding for the following reasons:

1. **Direct 21 CFR Part 11 §11.100/§11.200 violation**: Electronic records in GxP systems that attribute conclusions to qualified personnel require a valid electronic signature. LLM-generated text written without signature is an unsigned GxP record — inadmissible in regulatory submissions and a direct 483 observation risk.

2. **EU Annex 22 §7 violation**: Draft EU Annex 22 (2025) requires human-in-the-loop approval before any AI output is actioned in a GxP-critical path. The `overrideResult()` path bypasses this entirely.

3. **EU AI Act Article 14 violation**: High-risk AI systems require human oversight capability. A path that writes directly to quality records without human review removes oversight.

4. **Patient safety risk**: If AI-generated root cause text is written to a CAPA record without human review, the CAPA may be closed based on incorrect AI reasoning, potentially allowing a safety risk to persist.

The current High rating for the combined KD-003 finding is insufficient for Vulnerability B. Vulnerability B alone warrants Critical under the plan's own dual-dimension severity model (data integrity impact governs).

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.100, §11.200 — E-signature requirements
- EU Annex 11 §9, §12 — Data protection and access control in AI-adjacent paths
- EU Annex 22 (Draft 2025) §7 — Human-in-the-loop for critical AI decisions
- EU AI Act (2024/1689) Article 14 — Human oversight of high-risk AI
- OWASP LLM Top 10 (2025) LLM01 — Prompt Injection
- QS-21 (Verixa internal standard) — AI Output Segregation

**Recommendation**

1. Split KD-003 into two separate defect records: KD-003A (prompt injection) and KD-003B (`overrideResult()` direct write).
2. Reclassify KD-003B to Critical.
3. Raise a dedicated CAPA for KD-003B. The remediation path is: (a) remove or gate-guard the `overrideResult()` function so it cannot write to GxP fields without traversing the HITL module (`hitl_decisions` table); (b) require e-signature confirmation before any AI-suggested text is committed to a GxP record; (c) log the human acceptance event to the audit trail with `userId`, `timestamp`, and the AI model version that generated the suggestion.
4. Remove `describe.skip` from all 10 prompt injection test cases before Phase 4 (AI/LLM testing phase) begins.

---

### RF-005 — KD-004: Webhook SSRF — Blocklist Absent, Internal Metadata Endpoints at Risk

| Field | Detail |
|---|---|
| **Finding ID** | RF-005 |
| **Severity** | High |
| **Skill Perspective** | API Security Tester |
| **Location in Document** | Section 14, KD-004; Section 8 (Known Open Defects) |
| **Status** | CAPA required; test coverage adequate |

**Description**

KD-004 confirms that webhook configurations accept user-supplied URLs with only format validation and no IP/hostname blocklist. This is a Server-Side Request Forgery (SSRF) vulnerability. In a cloud-hosted environment (AWS/GCP/Azure), the primary risk is access to the instance metadata endpoint (e.g., `http://169.254.169.254/latest/meta-data/` on AWS). A successful SSRF to the metadata endpoint can yield IAM role credentials, enabling lateral movement to S3, RDS, or other cloud services within the VPC.

The current High rating is appropriate under CVSS v3.1 if the deployment environment's IMDSv2 enforcement is confirmed (IMDSv2 requires a PUT request to obtain a session token, which defends against simple GET-based SSRF). However, if IMDSv2 enforcement status is Unknown — evidence required, the risk may be higher.

**GxP / Regulatory Reference**

- OWASP API Security Top 10 (2023) API7 — Server Side Request Forgery
- OWASP ASVS v4.0.3 §V10.3.2 — DNS rebinding and SSRF

**Recommendation**

1. Confirm IMDSv2 enforcement status in the staging and production cloud environments. If unconfirmed, escalate KD-004 to Critical pending verification.
2. Implement a deny-list covering: all RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16), IPv6 link-local (fe80::/10), and all metadata endpoint IP ranges for AWS/GCP/Azure.
3. Implement DNS resolution at webhook dispatch time (not at configuration time) with a re-check against the blocklist before the outbound request is made, to prevent DNS rebinding attacks.
4. Raise a CAPA for KD-004 (currently `[CAPA-XXXX]`).

---

### RF-006 — Background Job Coverage: 31 Jobs, 3 Test Cases — Systematic Gap

| Field | Detail |
|---|---|
| **Finding ID** | RF-006 |
| **Severity** | High |
| **Skill Perspective** | Authorized Penetration Test Lead; API Security Tester |
| **Location in Document** | Test case area — Background Jobs (JOB-01 to JOB-03b) |
| **Status** | Coverage gap requiring plan amendment |

**Description**

The plan covers 31 background jobs but allocates only 3 test cases (JOB-01, JOB-02, JOB-03b). Background jobs in a GxP system are high-risk from both a security and data integrity perspective. Jobs run under system-level credentials, typically bypass user-facing permission checks, may write to GxP records without the standard audit trail flow, may trigger cross-tenant operations, and may process unvalidated queue payloads.

The test-case-to-job ratio of approximately 1:10 means that 28 background jobs receive no dedicated security test coverage. If any of these jobs: (a) write to GxP tables without calling `auditTrailService.log()`, (b) operate outside TDAL (violating QS-5), (c) process attacker-controlled queue payloads (job queue injection), or (d) run with elevated database privileges, these vulnerabilities will remain undiscovered.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.10(e) — Audit trail for all system operations including automated processes
- EU Annex 11 §9 — Data protection in automated operations
- QS-1 (Verixa internal standard) — Audit trail on every mutation including system-initiated

**Recommendation**

1. Enumerate all 31 background jobs by name and classify each as: (a) read-only monitoring, (b) GxP record mutation, (c) cross-tenant operation, (d) external integration trigger.
2. Add dedicated test cases for all Category (b), (c), and (d) jobs at minimum, covering: audit trail verification, permission enforcement, input validation on queue payloads, and tenant isolation.
3. Add a static analysis gate (Gate 4 equivalent) that scans all background job files for mutations without `auditTrailService.log()` calls as a supplement to manual test coverage.

---

### RF-007 — ASVS Version Decision: v4.0.3 in Use, v5.0 Released 2025 — No Decision Document

| Field | Detail |
|---|---|
| **Finding ID** | RF-007 |
| **Severity** | Medium |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Standards alignment section; test case mapping throughout |
| **Status** | Decision document required before plan freeze |

**Description**

The plan references OWASP ASVS v4.0.3 as the primary web application security verification standard. OWASP ASVS v5.0 was released in 2025 and contains material additions relevant to Verixa, including expanded API security controls, updated authentication requirements, and new sections on AI/ML-adjacent web security. No formal decision document exists in the plan explaining why v4.0.3 was retained rather than upgrading to v5.0, or documenting the delta assessment.

For a regulated system, the choice of a superseded standard version requires documented justification. During an FDA inspection or EU Annex 11 assessment, the auditor may query why the pentest did not align with the current version of the referenced standard.

**GxP / Regulatory Reference**

- EU Annex 11 §4.1 — Validation approach should reflect current good practice
- GAMP 5 (2nd ed.) — Use of current industry standards

**Recommendation**

1. Produce a brief decision document (1-2 pages) comparing ASVS v4.0.3 and v5.0 delta controls relevant to Verixa's attack surface. Document the decision to retain v4.0.3 (with justification) or upgrade to v5.0 (with gap analysis) before plan countersignature.
2. If v4.0.3 is retained, explicitly state in Section 2 of the pentest plan: "OWASP ASVS v5.0 was assessed; the delta controls not covered by v4.0.3 have been reviewed and are addressed by [specific test cases or are out of scope for the following reasons]."

---

### RF-008 — AI-09 Test Case Is a Confirmed Finding, Not a Prospective Test — Requires Annotation

| Field | Detail |
|---|---|
| **Finding ID** | RF-008 |
| **Severity** | High |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert; API Security Tester |
| **Location in Document** | AI-09 test case; Section 14 KD-003 |
| **Status** | Annotation required; test execution still needed for retest evidence |

**Description**

AI-09 (AI output direct write bypass) is listed as a prospective test case — implying an undiscovered vulnerability to be probed. However, KD-003 already confirms this exact vulnerability: `overrideResult()` writes LLM text to GxP fields without e-signature. The test case and the known defect describe the same code path.

This creates two problems:

1. **Result ambiguity**: If AI-09 is executed and the tester logs a finding, the finding may be closed as "duplicate of KD-003" without adequate investigation, potentially missing edge cases or additional attack vectors on the same path.

2. **Retest confusion**: When KD-003B is remediated and a retest is required, testers need to know that AI-09 is the retest vehicle for KD-003B, not a new standalone finding.

**GxP / Regulatory Reference**

- NIST SP 800-115 — Test case traceability and finding attribution
- 21 CFR Part 11 §11.10(e) — Evidence chain-of-custody for audit records

**Recommendation**

1. Annotate AI-09 in the test plan: "NOTE: This test case corresponds to confirmed defect KD-003B (`overrideResult()` direct write). Execution of AI-09 serves as both initial characterization evidence and the retest vehicle for KD-003B post-remediation. Log findings with cross-reference to KD-003B."
2. Add AI-09 to the go-live retest evidence list.
3. Ensure AI-09 tests multiple GxP field targets: `complaints.root_cause`, `deviations.investigation_conclusion`, `capas.action_description`, `batch_records.disposition` — not just one field.

---

### RF-009 — White-Box Trigger Tests TRIG-01/TRIG-02: DB Credentials Not Confirmed for Staging

| Field | Detail |
|---|---|
| **Finding ID** | RF-009 |
| **Severity** | High |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | TRIG-01, TRIG-02 test cases; Phase 0 prerequisites |
| **Status** | Phase 0 confirmation required |

**Description**

TRIG-01 and TRIG-02 are white-box tests that require runtime database credentials for the staging environment. The plan does not confirm that these credentials have been provisioned, that the access method is documented, or that the principle of least privilege has been applied to the test credentials (read-only vs. read-write). In a GxP staging environment, all credential provisioning must be traceable and auditable.

If testing proceeds without confirmed credential access, TRIG-01 and TRIG-02 will either fail to execute (test gap) or the tester will use production credentials (scope violation). Test credentials with excessive privileges (e.g., DBA-level access) could themselves become a security risk if not revoked immediately after testing.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.10(d) — Access control — no broader access than needed
- EU Annex 11 §12 — Controlled access to system data
- NIST SP 800-115 §3.1 — Authorization must cover credential provisioning method

**Recommendation**

1. Add to Phase 0 checklist: "Confirm read-only database credentials provisioned for TRIG-01/TRIG-02. Document credential owner, provisioning approver, and scheduled revocation date."
2. Explicitly state in the rules of engagement whether white-box DB access is read-only or read-write, with justification for read-write if required.
3. After testing, confirm credential revocation in the Phase 7 close-out checklist.

---

### RF-010 — Findings Register: 3 Placeholder Rows for a 180-Test Engagement

| Field | Detail |
|---|---|
| **Finding ID** | RF-010 |
| **Severity** | High |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Execution Document (.md) — Findings Register |
| **Status** | Must be corrected before Phase 1 begins |

**Description**

The findings register in the execution document contains only 3 placeholder rows. For a 180-test-case engagement with 4 pre-confirmed defects and the historical base rate of findings in regulated SaaS security engagements, the findings register will be inadequate within the first day of execution. An undersized register is not merely a cosmetic issue: in a GxP context, the findings register is the primary evidence artifact for the pentest. If it cannot accommodate all findings, testers will use ad-hoc channels (Slack, email, notes), creating attribution gaps and ALCOA+ violations.

Furthermore, the 4 pre-confirmed defects (KD-001 through KD-004) should already be pre-populated as rows 1-4 with finding IDs, severity, and status set to "Known — CAPA Pending."

**GxP / Regulatory Reference**

- ALCOA+ "Attributable" and "Complete" — all records must be attributed and complete
- NIST SP 800-115 — Findings documentation requirements
- 21 CFR Part 11 §11.10(e) — Contemporaneous recording

**Recommendation**

1. Expand the findings register template to a minimum of 60 rows.
2. Pre-populate rows 1-4 with KD-001 through KD-004, including severity, CAPA reference (once raised), and status.
3. Define in the execution document: the finding ID convention, the severity assignment process, the reviewer/approver fields, and the evidence artifact naming standard.

---

### RF-011 — Execution Document: Deliverables D-3 through D-7 Absent

| Field | Detail |
|---|---|
| **Finding ID** | RF-011 |
| **Severity** | High |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Execution Document (.md) — Deliverables Section |
| **Status** | Must be completed before plan countersignature |

**Description**

The execution document's deliverables list references only D-1 (Pentest Plan) and D-2 (Findings Register). For a 26-day, 7-phase engagement targeting a regulated go-live gate, the expected deliverable set should include at minimum: D-3 (Executive Summary Report), D-4 (Technical Findings Report with full evidence), D-5 (Remediation Tracking Register), D-6 (Retest Evidence Package), and D-7 (Go-Live Certification Letter or Attestation). The absence of D-3 through D-7 means there is no agreed output for the engagement. The test team has no contractual or documented obligation to produce a formal report, and Verixa has no documented artifact to present to regulators or auditors as evidence of the pentest.

**GxP / Regulatory Reference**

- EU Annex 11 §4.7 — Evidence of testing retained as part of validation lifecycle
- GAMP 5 — Testing deliverables as part of validation package
- NIST SP 800-115 §5 — Reporting phase deliverables

**Recommendation**

Define D-3 through D-7 (minimum) in the execution document with: deliverable name, format, owner, due date relative to engagement end, and recipient list. Include a clause specifying deliverable retention period (minimum 7 years for GxP records).

---

### RF-012 — Evidence Collection: SHA-256 Artifact Hash Missing from ALCOA+ Chain of Custody

| Field | Detail |
|---|---|
| **Finding ID** | RF-012 |
| **Severity** | High |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert |
| **Location in Document** | Execution Document (.md) — Evidence Collection Standard |
| **Status** | Must be added before Phase 1 |

**Description**

The evidence collection standard in the execution document does not specify that each collected artifact (screenshot, request/response capture, log extract, script output) must have a SHA-256 hash recorded at the time of collection. In a GxP context, the ALCOA+ "Original" principle requires that evidence can be demonstrated to be unmodified from the point of collection. Without artifact hashing, there is no cryptographic proof that a screenshot or log extract presented in the final report is the original artifact and has not been edited.

During an FDA inspection or EU Annex 11 audit, a finding backed by unhashed evidence is potentially challengeable. The regulator may argue that the evidence is not demonstrably original.

**GxP / Regulatory Reference**

- ALCOA+ "Original" — records must be original or certified true copies
- 21 CFR Part 11 §11.10(e) — Evidence integrity
- EU Annex 11 §9 — Data protection and audit trail integrity

**Recommendation**

Add to the evidence collection standard: "Each artifact collected during testing MUST have its SHA-256 hash computed at time of collection and recorded in the findings register alongside the artifact filename, collection timestamp, and collector user ID. The hash is the ALCOA+ Original control for pentest evidence."

---

### RF-013 — AUDIT-05: Automated Scan Should Cover All 57 Route Files, Not Manual/Custom Python Only

| Field | Detail |
|---|---|
| **Finding ID** | RF-013 |
| **Severity** | Medium |
| **Skill Perspective** | API Security Tester; GxP Part 11 / Annex 11 Expert |
| **Location in Document** | AUDIT-05 test case |
| **Status** | Test design enhancement required |

**Description**

AUDIT-05 tests for audit trail bypass on mutations. The current design relies on manual review and custom Python scripting. With 57 route files in the backend, manual coverage is unreliable and not repeatable. The Verixa CLAUDE.md Gate 4 already specifies an automated grep-based scan for mutations without `auditTrailService.log()` calls — this mechanism should be the primary evidence source for AUDIT-05, supplemented by dynamic testing.

A manual/custom approach also creates repeatability concerns: if the Python script is not version-controlled alongside the test plan, it cannot be re-executed for retest or annual reassessment in the same form.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.10(e) — Audit trail completeness
- EU Annex 11 §9 — Comprehensive audit trail coverage
- GAMP 5 — Automated testing for repeatable verification

**Recommendation**

1. Add to AUDIT-05: "Static analysis component: execute Gate 4 scan from CLAUDE.md verification gates against all 57 route files. Output must show zero mutations without `auditTrailService.log()`. Record scan output hash as evidence artifact."
2. Version-control any custom Python scripts used for dynamic testing in the engagement repository with a pinned commit hash referenced in the findings register.

---

### RF-014 — RBAC-15: Phase 0 Baseline Route Count Scan Not Specified

| Field | Detail |
|---|---|
| **Finding ID** | RF-014 |
| **Severity** | Medium |
| **Skill Perspective** | API Security Tester |
| **Location in Document** | RBAC-15 test case; Phase 0 checklist |
| **Status** | Phase 0 procedure enhancement required |

**Description**

RBAC-15's acceptance criterion correctly requires zero routes returning "Route does not have permission configuration." However, without a Phase 0 automated baseline scan establishing the total route count and the list of routes checked, it is impossible to verify that RBAC-15 covered the complete route surface. If new routes are added between Phase 0 and Phase 4, and these new routes lack permission configuration, RBAC-15 may pass for the original set while the new routes go unchecked.

**Recommendation**

Add to Phase 0: "Execute automated route enumeration scan. Record: total route count, list of all routes, and SHA-256 hash of the enumeration output as baseline artifact. RBAC-15 must be executed against this baseline, and any route additions between Phase 0 and Phase 4 must trigger a delta re-scan."

---

### RF-015 — TDAL-08: Dedicated Schema Mode Activation in Staging Not Confirmed

| Field | Detail |
|---|---|
| **Finding ID** | RF-015 |
| **Severity** | Medium |
| **Skill Perspective** | API Security Tester; GxP Part 11 / Annex 11 Expert |
| **Location in Document** | TDAL-08 test case |
| **Status** | Phase 0 confirmation required |

**Description**

TDAL-08 tests bypass of dedicated schema mode tenant isolation. If dedicated schema mode is not active in the staging environment, this test case is testing a configuration that does not reflect production, and the test result is not meaningful as production evidence. The plan does not confirm whether the staging environment uses dedicated schema mode or shared schema mode with RLS.

If dedicated schema mode is not active in staging, TDAL-08 should be documented as N/A with an explicit statement of why (configuration mismatch) and a note on when it will be retested. Leaving it as an active test case against a non-representative environment produces misleading evidence.

**GxP / Regulatory Reference**

- EU Annex 11 §4.5 — Testing in representative environments

**Recommendation**

Add to Phase 0 checklist: "Confirm whether staging environment uses dedicated schema mode or shared schema + RLS. If dedicated schema mode is not active in staging, annotate TDAL-08 as 'N/A — Configuration not present in staging environment' and document the compensating evidence source."

---

### RF-016 — IMP-02/IMP-03: ALCOA+ Attribution Tests Not Marked as Go-Live Gate Conditions

| Field | Detail |
|---|---|
| **Finding ID** | RF-016 |
| **Severity** | High |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert |
| **Location in Document** | IMP-02, IMP-03 test cases; Section 9 (Go-Live Gates) |
| **Status** | Go-Live gate addition required |

**Description**

IMP-02 and IMP-03 test impersonation audit attribution — specifically, whether audit trail records created during an impersonation session correctly attribute actions to the impersonating user (not the impersonated user) and whether the impersonation event itself is logged. These tests directly verify ALCOA+ "Attributable" compliance and 21 CFR Part 11 §11.10(e).

Despite their regulatory criticality, neither IMP-02 nor IMP-03 is marked as a go-live gate condition in Section 9. This means they could pass or fail without blocking go-live, which is incorrect for a 21 CFR Part 11 system where audit trail attribution is a fundamental compliance requirement.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.10(e) — Audit trail attributability
- ALCOA+ "Attributable" — every record traces to a person
- EU Annex 11 §9 — Audit trail data for all user and system actions

**Recommendation**

Add go-live gate G-7 (see Section 6 of this document) requiring IMP-02 and IMP-03 evidence filed and approved before go-live.

---

### RF-017 — ESIG-09b: Concurrent Signing Token Reuse Test Not a Go-Live Gate Condition

| Field | Detail |
|---|---|
| **Finding ID** | RF-017 |
| **Severity** | Critical |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert |
| **Location in Document** | ESIG-09b test case; Section 9 (Go-Live Gates) |
| **Status** | Go-Live gate addition required |

**Description**

ESIG-09b tests concurrent signing token reuse via Turbo Intruder — a race condition attack on the e-signature workflow. Under 21 CFR Part 11 §11.200, electronic signatures must be unique to their use and not reusable. If a concurrent signing token can be replayed, a single e-signature event can be counted as multiple approvals, which undermines the entire integrity of the GxP e-signature workflow. This could allow a record to be approved without the required number of distinct signatories, or allow approval of multiple records with a single signature event.

This is not merely a security finding — it is a 21 CFR Part 11 §11.200 compliance gap if confirmed. Yet ESIG-09b is not listed as a go-live gate condition. A failed ESIG-09b result means the e-signature system is non-compliant with Part 11 at go-live.

**GxP / Regulatory Reference**

- 21 CFR Part 11 §11.200(a)(1) — Electronic signatures must be unique and non-reusable
- EU Annex 11 §14 — E-signatures must be secured against reuse

**Recommendation**

Add go-live gate G-8 (see Section 6 of this document) requiring ESIG-09b retest evidence on file before go-live.

---

### RF-018 — Section 10: Annual Retest Schedule Missing AI Model Change Trigger

| Field | Detail |
|---|---|
| **Finding ID** | RF-018 |
| **Severity** | Medium |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert |
| **Location in Document** | Section 10 — Testing Cadence |
| **Status** | Plan amendment required |

**Description**

Section 10 specifies annual retest from September 2027. However, the MIRA AI component is classified as a High-Risk AI system under the EU AI Act (2024/1689) Article 6 and Annex III. The EU AI Act requires ongoing monitoring and re-assessment for high-risk AI systems when material changes occur. A new AI model, a provider switch, a significant prompt template change, or a model retraining event each constitutes a material change that requires security re-assessment — specifically of the AI gateway attack surface (prompt injection, AI output integrity, model output verification).

An annual-only cadence is insufficient for a platform with active AI model development.

**GxP / Regulatory Reference**

- EU AI Act (2024/1689) Article 72 — Post-market monitoring for high-risk AI
- EU Annex 22 (Draft 2025) §5 — Model change control and revalidation
- QS-22 (Verixa internal standard) — Model lifecycle and change control

**Recommendation**

Add to Section 10: "In addition to the annual retest cycle, a targeted security assessment of the AI gateway attack surface (minimum: AI-01 through AI-10 test cases) MUST be triggered by any of the following: (a) new AI model deployment or provider change; (b) material prompt template modification; (c) model retraining event; (d) new AI-adjacent module deployment. This trigger applies regardless of the annual retest schedule and is a requirement of EU AI Act Article 72 post-market monitoring obligations."

---

### RF-019 — KD-002 Reclassification Impact on Go-Live Gate G-1

| Field | Detail |
|---|---|
| **Finding ID** | RF-019 |
| **Severity** | High |
| **Skill Perspective** | Authorized Penetration Test Lead; GxP Part 11 / Annex 11 Expert |
| **Location in Document** | Section 9 (Go-Live Gates G-1, G-5); Section 14 KD-002 |
| **Status** | Go-Live gate logic correction required |

**Description**

The current plan assigns KD-002 (audit trail hash weakness) to gate G-5 (GxP-specific findings). If KD-002 is reclassified to Critical (as recommended in RF-003), it also triggers G-1 (zero Critical findings open at go-live). This is an important distinction: G-1 is the absolute blocking gate. If KD-002 remains open as Critical at go-live, the go-live is blocked regardless of any other gate status.

The plan as currently written does not reflect this dependency. A reader of Section 9 would not immediately understand that a severity reclassification of KD-002 would trigger G-1 and potentially extend the remediation window required before 01-Sep-2026.

**Recommendation**

1. Add a note to Section 9: "KD-002 is under severity review. If reclassified to Critical, it triggers G-1 (blocking gate). Remediation and retest evidence must be complete and approved before 01-Sep-2026 go-live. The remediation timeline for KD-002 (HMAC-SHA256 migration and audit record rehash) should be initiated immediately to preserve the go-live schedule."
2. Update the severity field for KD-002 in the plan once the reclassification decision is formally recorded in the CAPA.

---

### RF-020 — Prompt Injection Tests: `describe.skip` on All 10 Cases Is Unacceptable for Go-Live

| Field | Detail |
|---|---|
| **Finding ID** | RF-020 |
| **Severity** | High |
| **Skill Perspective** | API Security Tester |
| **Location in Document** | AI gateway test cases (prompt injection); KD-003A |
| **Status** | Must be resolved before Phase 4 execution |

**Description**

All 10 prompt injection test cases are marked `describe.skip` in the test suite. Skipped tests do not execute and do not produce evidence. For a go-live gate engagement, skipped security tests are equivalent to untested attack surface. OWASP LLM Top 10 (2025) LLM01 (Prompt Injection) is the highest-priority AI security risk class. The Verixa AI gateway's unsanitized `systemPrompt` field (confirmed by KD-003A) makes this attack surface active and exploitable.

Proceeding to go-live with 10 skipped prompt injection tests means the AI gateway's prompt injection resilience has never been assessed. This is an unacceptable gap for a system classified as High-Risk under the EU AI Act.

**GxP / Regulatory Reference**

- OWASP LLM Top 10 (2025) LLM01 — Prompt Injection
- EU AI Act (2024/1689) Article 9 — Risk management for high-risk AI systems
- EU Annex 22 (Draft 2025) §6 — AI system testing requirements

**Recommendation**

1. Remove `describe.skip` from all 10 prompt injection test cases before Phase 4 begins.
2. If the AI gateway remediation for KD-003A is not complete before Phase 4, execute the prompt injection tests against the current unmitigated state to characterize the full attack surface, then re-execute after remediation as retest evidence.
3. Add a Phase 0 checklist item: "Confirm zero `describe.skip` annotations on any test case in scope for this engagement."

---

### RF-021 — Go-Live Gate G-6: Retest Evidence Scope Underspecified

| Field | Detail |
|---|---|
| **Finding ID** | RF-021 |
| **Severity** | Medium |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Section 9, Gate G-6 |
| **Status** | Gate specification enhancement required |

**Description**

Gate G-6 requires retest evidence for remediated findings, but does not specify which findings require retest, who must approve retest results, or what constitutes acceptable retest evidence. In a regulated environment, this ambiguity means the gate can be passed with partial retest coverage.

**Recommendation**

Amend G-6 to specify: "Retest evidence required for: all Critical findings (by definition), all High findings, all known defects KD-001 through KD-004, and any finding where the remediation approach has not been independently verified. Retest evidence must include: test case ID, tester identity, execution date, outcome (Pass/Fail), and SHA-256 hash of the evidence artifact. Approval required from: [Security Lead name] and [Quality Lead name]."

---

### RF-022 — Phase 0 Checklist: Credential Inventory and Test Account Provisioning Not Formalized

| Field | Detail |
|---|---|
| **Finding ID** | RF-022 |
| **Severity** | Medium |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Phase 0 — Pre-Engagement Setup |
| **Status** | Phase 0 enhancement required |

**Description**

The plan references 11 test accounts across Tenant A, Tenant B, and platform roles, but does not include a formal Phase 0 checklist step for: verifying all 11 accounts are provisioned with the correct roles, verifying no test account has been accidentally granted production data access, confirming test accounts are isolated to the staging environment, and scheduling post-engagement deprovisioning. In a GxP system, test accounts that persist beyond the engagement represent an access control risk and a 21 CFR Part 11 §11.10(d) compliance gap.

**Recommendation**

Add a Phase 0 checklist item: "Provision all 11 test accounts. For each account record: username, role, tenant, provisioning approver, provisioning date, and scheduled deprovisioning date. Verify no test account has access to production data. Sign off in Phase 7 that all 11 accounts have been deprovisioned."

---

### RF-023 — Missing Deliverable: Formal Penetration Test Report (D-3) Not Defined

| Field | Detail |
|---|---|
| **Finding ID** | RF-023 |
| **Severity** | High |
| **Skill Perspective** | Authorized Penetration Test Lead |
| **Location in Document** | Execution Document (.md) — Deliverables |
| **Status** | Must be defined before plan countersignature |

**Description**

This finding specifically calls out the absence of D-3 (Formal Penetration Test Report) as distinguished from the findings register (D-2). The pentest report is the primary document that Verixa will present to regulators, customers, and auditors as evidence that a security assessment was conducted for the go-live gate. Without D-3 defined as a deliverable, there is no agreed report format, no agreed report owner, no agreed distribution list, and no agreed retention requirement.

**Recommendation**

Define D-3 as: "Formal Penetration Test Report. Format: structured document covering: executive summary, scope and methodology, findings summary (by severity), detailed findings (with evidence references), remediation status, go-live gate assessment, and tester attestation. Owner: [Test Lead name]. Due date: within 5 business days of Phase 7 close. Recipients: [Security Lead, Quality Lead, CISO, CTO]. Retention: minimum 7 years as GxP validation lifecycle record."

---

### RF-024 — HITL Module: Go-Live Gate Does Not Verify HITL Active for All Critical AI Paths

| Field | Detail |
|---|---|
| **Finding ID** | RF-024 |
| **Severity** | Medium |
| **Skill Perspective** | GxP Part 11 / Annex 11 Expert |
| **Location in Document** | Section 9 (Go-Live Gates); AI test cases |
| **Status** | Go-Live gate addition recommended |

**Description**

The go-live gates do not include a gate verifying that the HITL (Human-in-the-Loop) module is active and correctly configured for all critical AI paths (batch disposition predictions, OOS investigation AI, deviation classification, CAPA prioritization, complaint severity scoring). This is required by EU Annex 22 §7, EU AI Act Article 14, and QS-23. Without a HITL gate, the system could go live with HITL disabled or misconfigured for one or more critical paths without triggering a go-live block.

**GxP / Regulatory Reference**

- EU Annex 22 (Draft 2025) §7 — HITL for critical AI decisions
- EU AI Act (2024/1689) Article 14 — Human oversight
- QS-23 (Verixa internal standard) — HITL module mandatory for critical AI paths

**Recommendation**

Add to go-live gates: "G-9: HITL module active and configured for all critical AI paths. Evidence: `hitl_gate_config` table review confirming all critical module paths have `hitl_required = true`, escalation thresholds populated, and at least one full HITL workflow executed (AI output to human review to e-signature to action logged) for each critical path module."

---

## 4. GxP Security Control Review Table

| Control | 21 CFR Part 11 Reference | EU Annex 11 Reference | Current Plan Status | Gap Finding | Severity |
|---|---|---|---|---|---|
| Audit Trail Integrity (HMAC) | §11.10(e) | §9 | KD-002: Unkeyed SHA-256, no tenantId in payload — rated High | Should be Critical; blocks go-live if Critical | Critical (RF-003) |
| Audit Trail Completeness (All Routes) | §11.10(e) | §9 | AUDIT-05: manual/Python only for 57 routes | Add automated Gate 4 scan to AUDIT-05 | Medium (RF-013) |
| Audit Trail Attribution (Impersonation) | §11.10(e) | §9 | IMP-02/IMP-03: not marked as go-live gate | Must be go-live gate condition G-7 | High (RF-016) |
| Access Control (Authority Profiles) | §11.10(d) | §12 | KD-001: 4 profiles gate incorrectly; no CAPA raised | CAPA required immediately; profile IDs needed | Critical (RF-002) |
| E-Signature Integrity (Token Reuse) | §11.200(a)(1) | §14 | ESIG-09b: not a go-live gate condition | Must be go-live gate condition G-8 | Critical (RF-017) |
| AI Output Attribution to Human | §11.10(e), §11.200 | §9, §12 | KD-003B: `overrideResult()` writes LLM text without e-sig | Critical; direct Part 11 violation | Critical (RF-004) |
| Human-in-the-Loop for Critical AI | §11.10(d) | §12 | HITL gate not in go-live conditions | Add G-9 | Medium (RF-024) |
| Test Account Access Control | §11.10(d) | §12 | 11 accounts referenced; no Phase 0 provisioning checklist | Add Phase 0 credential inventory | Medium (RF-022) |
| Background Job Audit Trail | §11.10(e) | §9 | 31 jobs; 3 test cases; no static scan | Systematic gap | High (RF-006) |
| Evidence Original (ALCOA+) | §11.10(e) | §9 | No SHA-256 artifact hash in evidence standard | Add to evidence collection standard | High (RF-012) |
| Rules of Engagement Documentation | §11.10(e) | §4 | Section 3.1 has unfilled placeholders | Blocks countersignature | Critical (RF-001) |
| Prompt Injection Sanitization | — | §9 (AI-adjacent data integrity) | All 10 tests `describe.skip` | Must execute before go-live | High (RF-020) |

---

## 5. API Security Coverage Assessment

### OWASP API Security Top 10 (2023)

| Risk | Coverage in Plan | Gap / Risk | Severity |
|---|---|---|---|
| API1:2023 — Broken Object Level Authorization | Covered (AUTH-P-01 to AUTH-P-20, TDAL-01 to TDAL-11) | Adequate | — |
| API2:2023 — Broken Authentication | Covered (AUTH-01 to AUTH-12, ESIG series) | ESIG-09b not a go-live gate — see RF-017 | Critical |
| API3:2023 — Broken Object Property Level Authorization | Partial — mass assignment tests present | Verify mass assignment coverage for all 57 routes | Medium |
| API4:2023 — Unrestricted Resource Consumption | Unknown — evidence required | No rate-limiting or throttle test cases visible in plan summary | High |
| API5:2023 — Broken Function Level Authorization | Covered (RBAC-15, permission matrix tests) | RBAC-15 needs Phase 0 baseline — see RF-014 | Medium |
| API6:2023 — Unrestricted Access to Sensitive Business Flows | Partial — ESIG series covers signing flows | Background job flows uncovered — see RF-006 | High |
| API7:2023 — Server Side Request Forgery | Covered (KD-004, webhook tests) | CAPA not raised; IMDSv2 enforcement unconfirmed | High |
| API8:2023 — Security Misconfiguration | Unknown — evidence required | Cloud config tests not visible in plan summary | Medium |
| API9:2023 — Improper Inventory Management | Partial — RBAC-15 route inventory | Need Phase 0 baseline scan — see RF-014 | Medium |
| API10:2023 — Unsafe Consumption of APIs | Unknown — evidence required | Third-party API consumption (Anthropic, Azure OpenAI gateway) security test coverage not confirmed | High |

### OWASP LLM Top 10 (2025)

| Risk | Coverage in Plan | Gap / Risk | Severity |
|---|---|---|---|
| LLM01 — Prompt Injection | Planned but `describe.skip` on all 10 cases | Must execute before go-live — see RF-020 | Critical |
| LLM02 — Sensitive Information Disclosure | Unknown — evidence required | No test case visible for LLM output containing system prompt or tenant data | High |
| LLM03 — Supply Chain | Unknown — evidence required | Provider/model supply chain verification not referenced | Medium |
| LLM04 — Data and Model Poisoning | Not in scope per plan | Acceptable if AI model is static/deterministic per Annex 22 | — |
| LLM05 — Improper Output Handling | Covered by KD-003B / AI-09 | `overrideResult()` is the primary finding; needs Critical reclassification | Critical |
| LLM06 — Excessive Agency | Partially covered by HITL tests | HITL gate not in go-live conditions — see RF-024 | Medium |
| LLM07 — System Prompt Leakage | Unknown — evidence required | No test case for extracting system prompts via adversarial prompts | High |
| LLM08 — Vector and Embedding Weaknesses | Not in scope per plan | Acceptable if RAG not in production scope | — |
| LLM09 — Misinformation | Advisory scope — not security test | Covered by QS-21 advisory labeling requirement | — |
| LLM10 — Unbounded Consumption | Unknown — evidence required | No rate-limiting test on AI gateway endpoints | Medium |

---

## 6. Go-Live Gate Review

### Current Gates (G-1 through G-6) — Assessment

| Gate | Description | Current Status | Assessment |
|---|---|---|---|
| G-1 | Zero Critical findings open at go-live | Defined | Sound. Will be triggered by KD-002 and/or KD-003B if reclassified to Critical (see RF-003, RF-004) |
| G-2 | All High findings remediated or accepted with documented risk | Defined | Sound. Acceptance requires Quality Lead sign-off |
| G-3 | All test accounts deprovisioned | Defined | Add Phase 0 provisioning checklist as prerequisite (RF-022) |
| G-4 | No open placeholder fields in plan or execution document | Defined | Currently failing — Section 3.1 and CAPA references are unfilled (RF-001, RF-002) |
| G-5 | GxP-specific findings (Part 11, Annex 11) at zero Critical | Defined | Sound. Must reflect KD-002 reclassification |
| G-6 | Retest evidence filed for all remediated findings | Defined | Scope underspecified — see RF-021 |

### Recommended Additional Gates

| Gate | Description | Rationale | Finding Reference |
|---|---|---|---|
| G-7 | IMP-02 and IMP-03 retest evidence filed and approved by Quality Lead | 21 CFR Part 11 §11.10(e) ALCOA+ attributability — mandatory for audit trail compliance | RF-016 |
| G-8 | ESIG-09b retest evidence on file demonstrating no concurrent signing token reuse | 21 CFR Part 11 §11.200(a)(1) — e-signature uniqueness and non-reusability | RF-017 |
| G-9 | HITL module active and configured for all critical AI paths per `hitl_gate_config` | EU Annex 22 §7, EU AI Act Article 14, QS-23 — HITL mandatory for critical AI decisions | RF-024 |

---

## 7. Pre-Engagement Blockers

The following items MUST be resolved before Phase 0 can begin. Items 1-4 are authorization pre-conditions. Items 5-7 are execution safety pre-conditions.

| Blocker ID | Description | Finding Ref | Owner | Blocking Since |
|---|---|---|---|---|
| PEB-1 | Populate all `[INSERT: ...]` fields in Section 3.1 (test window dates, emergency contact, escalation tree) | RF-001 | Security Lead | Plan creation |
| PEB-2 | Raise 4 CAPA records in QMS for KD-001 through KD-004; populate all `[CAPA-XXXX]` references | RF-002, RF-003, RF-004, RF-005 | Quality Lead | Plan creation |
| PEB-3 | Identify the 4 failing authority profile IDs for KD-001; populate AUTH-P-07 precondition | RF-002 | Engineering Lead | Plan creation |
| PEB-4 | Reclassify KD-002 to Critical (audit trail hash weakness) and update go-live gate logic | RF-003, RF-019 | Security Lead + Quality Lead | Review date |
| PEB-5 | Reclassify KD-003B to Critical (`overrideResult()` direct write) and split KD-003 into KD-003A and KD-003B | RF-004 | Security Lead + Quality Lead | Review date |
| PEB-6 | Confirm runtime DB credentials provisioned for TRIG-01/TRIG-02 with least-privilege access and scheduled revocation | RF-009 | Infrastructure Lead | Phase 0 |
| PEB-7 | Remove `describe.skip` from all 10 prompt injection test cases before Phase 4 | RF-020 | Test Lead | Phase 4 start |

---

## 8. Positive Findings

The following design decisions in the plan are well-constructed and should be preserved.

| Positive | Description |
|---|---|
| Dual-Dimension Severity Model | The CVSS v3.1 plus Patient/Data-Integrity Impact model with "higher governs" is the correct approach for a regulated GxP platform. This reviewer endorses this model and recommends it as a standard for all future security assessments. |
| TDAL-01 to TDAL-11 Coverage | The 11-test-case TDAL coverage set is comprehensive. Testing dedicated schema bypass, RLS policy enforcement, TDAL skip patterns, and cross-tenant data bleed via multiple vectors reflects deep understanding of Verixa's multi-tenancy architecture. |
| 11 Test Accounts Across Role Hierarchy | Provisioning test accounts for viewer, reviewer, quality_lead, admin, platform_admin, and super_admin across two tenants and platform context enables genuine privilege escalation and cross-tenant isolation testing. This is more rigorous than most regulated SaaS engagements. |
| ESIG Series Coverage | The e-signature test series (ESIG-01 through ESIG-09b) is well-designed, covering replay, bypass, non-repudiation, and concurrent token reuse. ESIG-09b in particular is a test case that many engagements omit. |
| 7-Phase Structure with Phase 0 Dry-Run | The inclusion of a Phase 0 pre-engagement dry-run aligns with NIST SP 800-115 best practice and reduces execution risk in a regulated environment where disruption to the staging environment could impact parallel validation activities. |
| Go-Live Certification Gate Logic | The G-1 through G-6 gate structure with a clear blocking logic for Critical findings is the correct pattern for a Phase-2 production go-live gate. The addition of G-7, G-8, and G-9 (recommended above) will make it complete. |
| QS-21 AI Output Segregation Standard | The Verixa internal QS-21 standard (AI Output Segregation — Advisory vs. System-of-Record) reflects EU Annex 22 and EU AI Act requirements accurately and is among the most precise internal AI governance standards reviewed by this team. |
| Section 14 Pre-Confirmed Defects | Documenting known defects before testing begins is correct practice under NIST SP 800-115 and GxP. It prevents double-counting, ensures CAPAs are traceable to the right source, and demonstrates regulatory transparency. The mechanism is right; the execution (severity ratings, CAPA population) needs correction as detailed above. |

---

## 9. Appendix: Skill Frameworks Applied

### Framework 1: Authorized Penetration Test Lead

Applied to: engagement authorization completeness (RF-001), test account governance (RF-022), Phase 0 prerequisites (RF-009, RF-015), findings register adequacy (RF-010), deliverables completeness (RF-011, RF-023), go-live gate retest scope (RF-021), ASVS version decision (RF-007), background job coverage (RF-006).

Operating doctrine: PECRA + RICCE. No evidence invented. All findings based on stated plan facts or documented absences. Gaps marked "Unknown — evidence required" where applicable.

Dependency status: This skill depends on `regulated_platform_security_team_lead` and `security_risk_register_and_treatment_plan_expert`. Both are treated as active based on the GxP regulatory context provided. `security_remediation_program_manager` dependency applies to CAPAs and remediation timelines.

### Framework 2: API Security Tester

Applied to: KD-004 SSRF analysis (RF-005), API security coverage assessment (Section 5), OWASP LLM Top 10 gap analysis (Section 5), AUDIT-05 automation recommendation (RF-013), RBAC-15 baseline scan (RF-014), prompt injection `describe.skip` finding (RF-020), background job queue injection risk (RF-006), AI-09 annotation (RF-008), KD-003 AI gateway prompt injection component (RF-004).

Standard alignment: OWASP API Security Top 10 (2023); OWASP LLM Top 10 (2025); OWASP ASVS v4.0.3 (as plan-referenced); NIST SP 800-115.

### Framework 3: GxP Part 11 / Annex 11 Security Control Expert

Applied to: KD-002 severity reclassification (RF-003), KD-003B severity reclassification (RF-004), CAPA requirement for all known defects (RF-002), IMP-02/IMP-03 go-live gate requirement (RF-016), ESIG-09b go-live gate requirement (RF-017), HITL gate requirement (RF-024), SHA-256 evidence artifact hashing (RF-012), background job audit trail coverage (RF-006), TDAL-08 environment confirmation (RF-015), AI model change retest trigger (RF-018), GxP control review table (Section 4).

Regulatory basis: 21 CFR Part 11 (§11.10(d), §11.10(e), §11.100, §11.200); EU Annex 11 (§4, §9, §12, §14); EU Annex 22 Draft 2025 (§5, §6, §7); EU AI Act (2024/1689) Articles 9, 13, 14, 72; ALCOA+ (WHO TRS 996 Annex 5); ICH Q10 §3.2.2; GAMP 5 2nd ed.

---

*End of Verixa Pentest Plan v7.0 — Security Review Feedback v1.0*

*This document is a security-sensitive record and must be retained in the Verixa QMS under controlled access. Distribution is restricted to the Verixa Security Team, Quality Team, and named reviewers.*