# Innovexus Penetration Test — Vendor RFP Brief

**Purpose:** This document is the brief Innovexus sends to penetration-testing firms when soliciting bids for an annual external pen-test. It defines scope, methodology expectations, deliverables, timeline, and the questions every responding vendor should answer.

**Use:** Email this document, slightly customised, to 3–5 reputable firms. Compare responses on a structured rubric. Engage one. Repeat annually.

**Recommended firm shortlist (for evaluation, not endorsement):**
- NCC Group
- Trail of Bits
- Bishop Fox
- Cure53 (especially for web/cloud-app focus)
- Praetorian
- Doyensec (for code-heavy review)
- Independent Security Evaluators (ISE)

Boutique firms with strong reputations in this category include: Atredis Partners, Latacora, Specter Ops, Include Security.

---

## 1. About Innovexus

Innovexus is a unified PAM, NOC, and SOC SaaS platform for mid-market network and security teams. Customers receive dedicated per-tenant infrastructure ("pods") on SOC 2 Type II audited hosting (RunPod Secure Cloud).

**Core security-relevant components:**

- Per-tenant pod with isolated compute, vault, and audit storage
- AES-256-GCM credential vault with HSM-backed master keys (AWS CloudHSM, FIPS 140-2 Level 3)
- Privileged session brokering layer (SSH, Telnet, console, RDP)
- FIDO2/WebAuthn authentication at platform login (YubiKey-class)
- SAML 2.0 / OIDC federation with customer IdPs
- Hash-chained, signed audit log per tenant
- Public-website AI chat agent (ElevenLabs ConvAI) — tightly scoped, no auth
- PKI subsystem for ephemeral SSH cert issuance (per-tenant CA)
- Public marketing site (Next.js on Cloudflare CDN)

**Sub-processors (full list at innovexus.io/trust/sub-processors):** RunPod, AWS, Anthropic, ElevenLabs, Stripe, Supabase, Cloudflare.

**Compliance posture:** Innovexus does not independently hold SOC 2 Type II or ISO 27001 (we inherit hosting attestations). The pen-test report supports the Innovexus-issued SOC 2-style evidence package we share with customers under NDA.

---

## 2. Scope of test

The annual engagement should cover all of the following surfaces:

### 2.1 Public web application (in scope)

- `innovexus.io` marketing site, blog, /compare, /platform, /pricing, /trust pages
- Authentication and registration flows (`/auth/*`)
- Public APIs: `/api/compliance/posture`, `/api/innovexus/health`, `/api/cron/*` (if accessible from external network), IndexNow submission endpoint
- The "Inno" public chat agent — both the embedded widget and the underlying ElevenLabs flow

### 2.2 Authenticated customer portal (in scope)

- `innovexus.io/dashboard` and all sub-routes after authenticated login
- Customer pod management surface (provisioning, configuration, settings)
- Privileged session brokering UI (initiation, recording playback, audit search)
- Vault administration UI
- Compliance evidence export flows
- Admin / RBAC settings

### 2.3 Per-tenant pod APIs (in scope, per-tenant)

A test tenant will be provisioned for the engagement. Its pod will be made available with realistic but anonymised inventory. Pod surface includes:

- Internal pod APIs the dashboard consumes (REST and WebSocket)
- Session broker entry/exit points
- Audit chain endpoints
- Credential rotation triggers

### 2.4 Identity and authentication (in scope)

- FIDO2/WebAuthn login flow
- SAML/OIDC SSO flows with major IdPs (Okta, Azure AD)
- SCIM 2.0 provisioning (Professional and Enterprise tiers)
- Local-username fallback authentication
- Emergency-access ("break-glass") workflow

### 2.5 Cryptographic boundaries (in scope)

- Vault encryption at rest (verify AES-256-GCM, key custody)
- Audit chain integrity (verify hash chain, signature validation)
- TLS configuration (cipher suites, certificate pinning if any)
- PKI subsystem (per-tenant CA, ephemeral cert TTLs, OCSP/CRL behaviour)

### 2.6 Out of scope (explicitly excluded from this engagement)

- The underlying hosting infrastructure (RunPod) — that's RunPod's own pen-test responsibility
- Third-party sub-processors' own infrastructure (Anthropic, ElevenLabs, Stripe, etc.)
- Physical security of data centres
- Customer-side endpoints (engineer laptops, etc.)
- Customer-managed integrations into Innovexus from their own SIEM, ITSM, etc.
- Social engineering of Innovexus staff (separate engagement, if pursued)
- DDoS testing (separate engagement, with hosting partner notification required)

---

## 3. Methodology expectations

The vendor's proposed methodology should explicitly address:

### 3.1 Testing classes

- **Black-box and grey-box** mix. We provide test tenant credentials and a brief architecture walkthrough; we do not provide source code by default. Code review (white-box) available as an optional add-on.
- **Manual testing primary**, automated tooling secondary. Reports listing only Burp Suite or Nessus output will not satisfy the engagement.
- **Authenticated and unauthenticated paths** both exercised on every in-scope surface.
- **Cryptographic review** of vault/audit chain by someone with explicit cryptography credentials, not just web-app generalists.

### 3.2 Threat-model alignment

The engagement should at minimum exercise:

1. **Multi-tenant isolation breach** — can Tenant A's credentials, sessions, or audit data be reached from Tenant B?
2. **Vault compromise paths** — what does an attacker with engineer-level access to the dashboard see? With operator-level? With direct DB access if they got it?
3. **Audit chain tampering** — can session records be modified or deleted without detection?
4. **Privileged-session escape** — can a brokered SSH session escape to the underlying pod or to a different tenant?
5. **Authentication bypass** — FIDO2 flows, SAML/OIDC flows, SCIM provisioning, fallback paths.
6. **Cryptographic flaws** — key custody, weak configurations, TLS downgrade, replay, etc.
7. **Public-API abuse** — IndexNow, /api/compliance/posture, the Inno chat agent's underlying flow.
8. **Supply-chain attack vectors** — sub-processor compromise scenarios.

### 3.3 Reporting standard

- **Findings categorised by:** OWASP Top 10 (web), CWE ID (where applicable), CVSS 3.1 base score, Innovexus-specific severity (Critical / High / Medium / Low / Info)
- **Each Critical and High finding:** reproduction steps, screenshots, suggested remediation, retesting plan
- **Executive summary** suitable for board/customer redaction (~2 pages)
- **Technical detail** suitable for engineering remediation (~30+ pages typical)
- **Customer-facing redacted version** that we can share under NDA without disclosing specific exploit chains

---

## 4. Deliverables

The engagement must produce:

1. **Kickoff document** — agreed scope, in/out boundaries, contact list, escalation path
2. **Weekly status check-in** during the test (15 min, async OK)
3. **Critical-finding immediate notification** — any Critical-severity issue notified to security@innovexus.io within 1 business day of discovery; the test paused until acknowledged
4. **Draft report** within 10 business days of test completion
5. **Final report** within 15 business days of test completion, after Innovexus engineering has reviewed the draft
6. **Retest of remediated Critical and High findings** included in the engagement scope (one round)
7. **Customer-redacted version** of the final report, suitable for sharing under NDA
8. **Executive summary** suitable for inclusion in the Innovexus customer trust package

---

## 5. Timeline

- Kickoff: TBD by negotiation, typical 2–4 weeks after engagement start
- Active testing: 2–4 weeks (depending on scope and team size)
- Draft report: within 10 business days of testing complete
- Final report: within 15 business days of testing complete
- Retest of remediated findings: within 30 days of final report
- Annual cadence: re-engage 12 months after final report, with optional mid-year mini-engagement focused on any new major surface area shipped during the year

---

## 6. Vendor questions

Please respond to these in your proposal:

### 6.1 Firm credentials

1. How long has the firm been operating? Approximate headcount of testers?
2. List 3 references from clients in the SaaS PAM, security operations, or fintech space (under NDA acceptable).
3. Provide a sanitised sample report demonstrating your standard deliverable depth.

### 6.2 Team

4. Who is the proposed lead tester for this engagement? Their CV, certifications (OSCP, OSCE, GPEN, GXPN, CRTO, etc.), relevant prior engagements.
5. Who is the proposed cryptographic specialist? Their credentials. (Required.)
6. What is the team size on the engagement? Test hours per role?

### 6.3 Methodology

7. How do you scope multi-tenant isolation testing for a per-tenant SaaS architecture?
8. What is your standard methodology for testing FIDO2/WebAuthn authentication? Have you found vulnerabilities in similar implementations before?
9. How do you approach cryptographic review of HSM-backed key custody?
10. Do you provide source-code review as part of the engagement, or as a separate offering? If separate, pricing for the add-on.

### 6.4 Commercial

11. Total fixed-price quote for the scope above, broken down by phase (kickoff, testing, reporting, retest)
12. What is excluded from the fixed price that we should expect to be billed extra?
13. Hourly rate for out-of-scope follow-up work (we may ask for additional targeted testing during the year)
14. Cancellation and reschedule terms
15. Insurance coverage (errors & omissions, cyber liability)

### 6.5 References-on-reference

16. May we contact at least one of your references directly? (Yes/No)
17. May we share your final report (redacted) with our customers as part of our trust package? (Yes/No, and any conditions)
18. Do you maintain an archive of report formats from prior engagements that we can review with NDA? (Yes/No)

---

## 7. Evaluation rubric (internal — for whoever scores responses)

Score each vendor 0–3 on the following dimensions:

| Dimension | Weight |
|---|---|
| Demonstrated experience in SaaS PAM / privileged-access category | 20% |
| Proposed methodology depth and threat-model alignment | 20% |
| Cryptographic specialist credentials | 15% |
| Sample report quality | 15% |
| Reference quality (named, contactable, recent) | 10% |
| Pricing relative to scope | 10% |
| Timeline alignment with our needs | 5% |
| Insurance / commercial maturity | 5% |

Total = 100%. Vendors scoring 80%+ proceed to a 30-min call. Vendors scoring 90%+ are eligible for selection.

---

## 8. Budget guidance (internal)

For the scope defined above, expected pricing range:

- **Boutique firm (3-person team, 3-week engagement, full report):** $35,000–$60,000
- **Mid-tier firm (Bishop Fox, NCC mid-tier, similar):** $60,000–$100,000
- **Tier-1 firm (NCC enterprise, Trail of Bits, similar):** $100,000–$180,000
- **Annual retainer with quarterly mini-engagements:** $80,000–$150,000

These are rough industry ranges as of 2026 and will vary. The pricing range is information for negotiation, not a procurement constraint.

For mid-market PAM with the customer trust requirement Innovexus has, the **mid-tier firm range** is the right target. Tier-1 firms over-deliver for the surface area; boutique firms may under-cover the cryptographic review depth.

---

## 9. After the test

Once the final report lands:

1. Engineering remediates Critical and High findings on the documented timeline (typically 30 days for Critical, 60–90 days for High)
2. Vendor performs the included retest
3. Innovexus updates the public security whitepaper at `/trust/security` to reference the most recent test date and the test firm
4. The customer-redacted version becomes part of the NDA-shareable security package available via `trust@innovexus.io`
5. A line item appears on the next quarter's status review summarising findings categories (without disclosing specific exploits)

---

## 10. Send to

Email proposals to: `trust@innovexus.io`

Response deadline: 10 business days from this brief being sent.

Questions during the response window: same address, response within 1 business day.

---

## Licence

This brief is released under [Creative Commons Attribution 4.0](https://creativecommons.org/licenses/by/4.0/). Other vendors evaluating PAM platforms are welcome to adapt the structure for their own pen-test procurement.

## Source

[innovexus.io/resources/innovexus-pentest-rfp-brief.md](https://innovexus.io/resources/innovexus-pentest-rfp-brief.md)
