Deloitte Partner Integration Strategy

Date: 2026-03-13 Status: Working document — pre-first-client, planning phase Audience: Internal (founders, engineering); Deloitte partnership team

---

Overview

SecurityV0 has not yet deployed to any production clients. This is a strategic asset: we can design our deployment and commercial model correctly from the start rather than retrofitting it later. This document defines our options across deployment topology, data governance, licensing, IP protection, and operational management — structured to answer Deloitte's due diligence questions and to guide our own roadmap decisions.

---

Part 1: Crisp Answers for Deloitte (Use with Clients)

These are the concise, customer-ready answers to the questions Deloitte's team needs when presenting to their clients.

Where data is processed

SecurityV0 processes only security metadata — automation definitions, identity relationships, role assignments, and ownership mappings. No business content, no application data, no payload data.

Processing location depends on the deployment model chosen:

• Vendor-hosted (EU): All processing occurs in EU infrastructure (AWS eu-west-1 Ireland or eu-central-1 Frankfurt). Data never leaves the EU region.
• Partner-hosted: Processing occurs in Deloitte's own infrastructure in a region of their choosing.
• Customer-hosted: Processing occurs entirely within the customer's environment. Data never leaves the customer's network.

EU hosting availability

Yes. EU hosting is available as a standard option, not an add-on.

• Primary EU region: AWS eu-west-1 (Ireland)
• Secondary EU region: AWS eu-central-1 (Frankfurt)
• All data at rest encrypted with AWS KMS single-region keys (data unreadable outside the configured region)
• AWS GDPR Data Processing Addendum in place
• Full Data Processing Agreement (DPA) available for customer contracts

Retention period

Data category	Default retention	Maximum (configurable)
Security scan results (authority paths, findings)	12 months	24 months
Identity and automation metadata snapshots	12 months	24 months
Audit logs of platform activity	12 months	36 months
Operational/infrastructure logs	90 days	90 days
Data after contract termination	Deleted within 30 days	—

Retention periods are configurable per customer. Customers receive a deletion certificate upon request following contract termination.

Deletion policy

• All customer data is deleted within 30 days of contract termination.
• Customers may request early deletion at any time; fulfilled within 30 days.
• Backup copies are purged within 90 days following production deletion (standard backup rotation).
• A signed deletion certificate is provided upon completion.
• GDPR Article 17 (Right to Erasure) requests are processed within 30 days.
• TTL-based automated deletion is enforced at the database level — no manual process dependency.

What exact metadata is collected

SecurityV0 collects the following metadata from connected systems:

From Microsoft Entra ID / Azure:

Data collected	Purpose
Service principal display name, app ID, object ID	Identity inventory
Owner UPN and account status (enabled/disabled)	Ownership validation
Role assignments (role name, scope, principal)	Authority mapping
OAuth grants (resource, scopes)	Permission surface
Sign-in activity counts (not individual session data)	Dormancy detection
Managed identity bindings	Execution identity mapping
Azure AI Foundry agent definitions and connections	Autonomous execution discovery

From ServiceNow:

Data collected	Purpose
Integration registration names and IDs	Automation inventory
Flow and script metadata (name, trigger description, type)	Automation classification
Outbound API connection endpoints	Reachable system mapping
API user account name and status	Ownership validation
Automation owner metadata	Accountability chain

From AWS (extracted today, shipped 2026-05):

Data collected	Purpose
IAM users, roles, groups, policies, federation providers (OIDC/SAML), access-key last-used signals	Identity inventory and permission surface
Bedrock agent definitions, action groups, knowledge bases, flows, guardrails	AI agent inventory
Lambda function configuration (including environment variables and code-download URL — customers should not store secrets in Lambda env vars), ECS service and task definitions, Step Functions state machines, EventBridge rules + targets + API destinations, SNS topic attributes	Automation inventory
ECR repository policies, lifecycle policies, image manifests	Container image metadata
S3 bucket settings only (location, policy, encryption, public-access-block, logging) — not bucket contents (default mode)	Data store metadata
DynamoDB table descriptions	Data store metadata
Secrets Manager secret names and resource policies — not secret values	Credential metadata
SSM Parameter Store parameter names — not parameter values	Configuration metadata
CloudTrail trail config and event metadata (cloudtrail:LookupEvents)	Audit signal
AWS Organizations account list, OU structure with full upward traversal (ListParents), SCPs (org-mode only)	Multi-account scope mapping
Optional, opt-in only: CloudTrail S3 archive log objects from a single customer-designated bucket (set via CloudTrailBucketArn template parameter)	Long-window execution evidence beyond the 90-day LookupEvents API window

On the canonical CFN, not yet extracted: IAM Identity Center, EKS Pod Identity, KMS, AWS Config, Access Analyzer. These are reserved for upcoming connector features and will not be silently activated.

The full enumerated permission set is in the canonical CloudFormation template at sv0-connectors/integrations/aws/cfn/securityv0-readonly-role.yaml. For the partner-friendly customer-handout version, see AWS Access — Customer Summary.

What is explicitly NOT collected

• Passwords, secrets, or authentication credentials of any kind
• Personal files, mailbox content, calendar data, or communications
• Business records: ticket conversations, incident payloads, attachments, invoice data
• Application data, database content, or storage contents
• Network traffic, endpoint telemetry, or behavioral data
• Bulk user enumeration beyond automation owners and integration accounts
• Model outputs, prompts, inference data, or AI training data
• Any data beyond identity relationships and automation definitions

Deployment options: vendor-hosted EU vs. partner/customer-hosted

Three deployment models are available:

Model	Description	Who manages	Data location
Vendor-hosted (EU SaaS)	SecurityV0 operates the platform in EU cloud. Customer provides read-only API credentials. Nothing installed in customer environment.	SecurityV0	EU cloud (customer's choice of region)
Partner-hosted	Deloitte operates the platform within their own infrastructure. SecurityV0 provides Docker images. Customer grants credentials to Deloitte.	Deloitte	Deloitte's infrastructure
Customer-hosted (self-hosted)	Customer runs the platform within their own environment (on-prem, private cloud, or their own cloud account). SecurityV0 provides Docker images and configuration.	Customer	Customer's environment

All three models support the same feature set. Deployment model choice does not affect what is discovered or what findings are generated.

---

Part 2: Deployment Strategy — Our Options and Tradeoffs

The Three Models in Detail

Option A: Vendor-Hosted EU SaaS (Standard Offer)

SecurityV0 operates a multi-tenant or single-tenant platform instance in AWS eu-west-1 or eu-central-1.

How it works:

• Customer provides read-only API credentials (OAuth2 client credentials, certificates, or managed identity federation)
• SecurityV0 connectors call customer APIs remotely over HTTPS — nothing installed in the customer environment
• Findings and evidence are stored in SecurityV0's EU infrastructure
• Customer accesses results via the SecurityV0 web UI

Advantages:

• Fastest onboarding (15–30 minutes from credentials to first scan)
• SecurityV0 handles all maintenance, updates, scaling, and monitoring
• Lowest cost per customer
• Easiest for Deloitte to present to clients — no infrastructure commitment required

Limitations:

• Customer data (metadata) transits to SecurityV0's infrastructure
• Not suitable for air-gapped environments
• Some highly regulated buyers will reject any external SaaS

When to offer: Default for all new engagements. 80% of enterprise clients will accept this model with a GDPR DPA in place.

---

Option B: Partner-Hosted (Deloitte-Operated)

Deloitte runs SecurityV0 on their own managed infrastructure. Deloitte becomes the operational party responsible for the deployment. SecurityV0 provides Docker images via a private registry.

How it works:

• SecurityV0 ships Docker images to a private container registry accessible to Deloitte
• Deloitte deploys and operates the stack (API, UI, database) in their own environment
• Deloitte manages credentials, backup, updates, and client access
• SecurityV0 provides L3 support; Deloitte handles L1/L2

Advantages:

• Customer data never leaves Deloitte's environment (or a Deloitte-managed cloud)
• Strong story for clients with data residency or regulatory requirements
• Deloitte can offer this as part of a managed security service SOW
• Enables Deloitte to bundle SecurityV0 into a broader managed service

Limitations:

• Deloitte must have infrastructure and operational capability
• SecurityV0 has less visibility into health and version state of deployments
• Requires license enforcement built into the container (see Part 4)
• Updates require Deloitte to pull new images and redeploy

When to offer: For Deloitte MSP engagements, and for enterprise clients who require data to stay within Deloitte's managed environment.

---

Option C: Customer Self-Hosted

The customer runs SecurityV0 entirely within their own infrastructure. SecurityV0 provides Docker images and documentation. No SecurityV0 infrastructure is involved.

How it works:

• SecurityV0 provides signed Docker images via a customer-scoped private registry
• Customer deploys and operates the stack (on-prem servers, private cloud, Kubernetes, Azure Container Apps, etc.)
• Customer manages everything — credentials, backups, updates
• SecurityV0 provides documentation and support but has zero operational access

Advantages:

• Maximum data control — data never leaves the customer's environment
• Suitable for air-gapped deployments
• Required for highly regulated sectors (defense-adjacent, government, financial services with strict data sovereignty)
• Strongest IP boundary — customer cannot access competitors' data even in principle

Limitations:

• Highest operational burden on the customer
• SecurityV0 cannot push updates, cannot monitor health, cannot assist without explicit support access
• Air-gapped deployments require offline license file distribution
• Longest onboarding timeline (days to weeks depending on customer IT)

When to offer: For clients who explicitly require full data sovereignty or air-gapped operation. Price this as a premium SKU — the operational support cost is higher.

---

Recommended Rollout Sequence

Phase 1 (Now — first 3 clients):
  → Vendor-hosted EU SaaS only
  → Single-tenant instances per client (separate DB, separate encryption keys)
  → Build tenant isolation correctly from the start

Phase 2 (3–6 months, after Deloitte partnership signed):
  → Partner-hosted model for Deloitte MSP engagements
  → Keygen license enforcement wired into containers
  → Private GHCR registry with license-scoped pull credentials

Phase 3 (6–12 months, enterprise demand):
  → Customer self-hosted with offline license support
  → Air-gapped bundle delivery
  → SOC 2 Type II certification complete

---

Part 3: Data Residency Architecture

EU Infrastructure Design

All vendor-hosted deployments are pinned to EU from day one:

Primary:   AWS eu-west-1 (Ireland)
Secondary: AWS eu-central-1 (Frankfurt)

Controls:
  ├── AWS KMS: single-region keys (data unreadable outside region)
  ├── AWS SCPs: deny resource creation outside EU regions
  ├── AWS GDPR DPA: signed and active
  └── Subnet config: no cross-region replication

What Personal Data We Hold and Why

SecurityV0 handles a narrow set of personal data as an unavoidable part of its security function:

Personal data	Why collected	Legal basis (GDPR)
Automation owner email/UPN	Determine whether automation is owned by an active employee	Art. 6(1)(f) — legitimate interests
Owner account status	Detect orphaned automations	Art. 6(1)(f) — legitimate interests
Service account names	Identify and inventory non-human identities	Art. 6(1)(f) — legitimate interests
Sign-in activity counts	Dormancy detection (no individual sessions stored)	Art. 6(1)(f) — legitimate interests

No bulk user enumeration. No employee behavioral data. No personal communications.

Data Processing Agreement

A DPA covering the above must be signed before any vendor-hosted deployment. The DPA specifies:

• Data categories and legal basis
• Retention schedule (linked to table in Part 1)
• Sub-processor list (AWS as IaaS, MongoDB Atlas if used, Keygen for licensing)
• Deletion workflow and certification
• DSAR (Data Subject Access Request) process: 30-day SLA
• Breach notification: 72 hours to customer, as required by GDPR Art. 33

---

Part 4: IP Protection and Licensing

The Core Principle

SecurityV0 distributes compiled binaries in Docker images. Source code is never provided to partners or customers. IP protection is enforced through:

1. Legal: Commercial EULA binding on all deployments
2. Technical: License key validation at container startup
3. Registry access: Pull credentials tied to active license status

License Enforcement Architecture

┌────────────────────────────────────────────────────┐
│  Container startup sequence                        │
│                                                    │
│  1. Entrypoint reads LICENSE_KEY env var           │
│     (or /run/secrets/license for Docker secrets)   │
│                                                    │
│  2. For connected deployments:                     │
│     → POST license key to Keygen API               │
│     → Validate: customer_id, expiry, features,     │
│       node count                                   │
│     → Cache validation for 24h (grace: 72h)        │
│     → On failure after grace period: exit 1        │
│                                                    │
│  3. For air-gapped deployments:                    │
│     → Read signed license file (RSA-256)           │
│     → Verify signature against embedded public key │
│     → Check expiry, installation_id, hardware      │
│       fingerprint                                  │
│     → On failure: exit 1 with clear error message  │
└────────────────────────────────────────────────────┘

License File Contents (JWT, signed with SecurityV0 private key)

{
  "customer_id": "deloitte-client-abc",
  "installation_id": "inst_xxxx",
  "issued_at": "2026-03-13",
  "expires_at": "2027-03-13",
  "features": ["azure", "servicenow", "foundry"],
  "max_nodes": 1,
  "deployment_model": "partner-hosted",
  "partner_id": "deloitte"
}

Registry Access Control

Private registry: ghcr.io/securityv0/sv0-platform

Access model:
  ├── Each customer/partner gets a scoped deploy token
  ├── Token is valid only while license is active
  ├── Token is revoked automatically on license expiry via Keygen webhook
  └── Token scoped to specific image tags matching their license tier

Tooling

• License management platform: Keygen (API-first, supports machine-locking, floating licenses, webhooks)
• Air-gapped support: Cryptlex (if needed, handles offline activation)
• Container registry: GitHub Container Registry (GHCR) — already part of our CI/CD

What Partners and Customers Cannot Do (EULA)

The EULA must explicitly prohibit:

• Reverse engineering, decompiling, or disassembling the images
• Redistributing images to third parties not covered by the license
• Using the software in a competing product
• Running more nodes/installations than licensed
• Removing or circumventing license enforcement

---

Part 5: Operational Model — Managing Multiple Installations

The Core Challenge

When Deloitte deploys SecurityV0 for 10, 20, or 50 clients, we need visibility and control without operational overhead proportional to the number of deployments.

Visibility Per Deployment Model

Model	Our visibility	Update control	Health monitoring
Vendor-hosted	Full (we operate it)	Automatic	Full
Partner-hosted	License telemetry only	Pull-based (Deloitte pulls)	Via Deloitte
Customer self-hosted	License telemetry only	Manual (customer pulls)	None without support access

License Telemetry (Connected Deployments)

Every running instance phones home to Keygen/our telemetry endpoint every 24 hours with:

• installation_id — which deployment
• version — which image tag is running
• features_active — which connectors are enabled
• scan_count — number of scans run (no customer data)
• license_status — valid/expiring/expired

This gives us a live dashboard of all active installations without accessing any customer data.

Update Delivery

Vendor-hosted: We push updates. No customer action required.

Partner-hosted (Deloitte):

• Images are published to GHCR with semantic tags: v1.2.3, v1.2, v1
• Deloitte subscribes to release notifications (GitHub releases + webhook)
• Deloitte pins to v1.x and pulls patch updates on their maintenance schedule
• Major version upgrades are communicated 30 days in advance with a migration guide

Customer self-hosted:

• Same image pull mechanism, or
• For air-gapped: signed update bundle (tarball of images + checksums), delivered via secure file transfer
• Customer's internal registry mirrors the images

Support Tiers (Deloitte Partnership)

Tier	Who handles	Scope
L1	Deloitte	Onboarding, configuration, credential setup, UI questions
L2	Deloitte	Connector troubleshooting, integration-specific issues
L3	SecurityV0	Bugs, platform issues, security incidents, license issues

L3 escalation path: Deloitte opens a ticket via a dedicated Slack channel or email alias. SLA: 4-hour acknowledgement for P1, 24-hour for P2.

Version Management

Supported versions policy (target):
  ├── Current minor release: fully supported
  ├── Previous minor release: security patches only (6 months)
  └── Older: end of life — customer must upgrade

Document this in the EULA and partner agreement. Enterprise customers want a clear EOL policy before committing.

---

Part 6: Deloitte Partnership Structure

Recommended Model: Phased Approach

Phase 1 — Referral Agreement (immediate)

Simplest to execute. Deloitte introduces SecurityV0 to clients; SecurityV0 closes the deal; Deloitte receives a referral fee.

• Referral fee: 12% of first-year ACV per closed deal
• Deloitte holds no license, no data, no customer relationship
• SecurityV0 owns the customer contract
• Setup time: one-page referral agreement, 1–2 weeks to execute

This gets the first deals done without complex legal negotiation. Prove the model works.

Phase 2 — Reseller / SI Agreement (after 2–3 referral deals)

Deloitte resells SecurityV0 licenses as part of their security assessment SOW. Deloitte holds the customer contract and invoices the client.

• Deloitte discount: 18–22% off list price
• Partner-hosted deployment model available at this tier
• Deloitte does L1/L2 support; SecurityV0 does L3
• Requires: reseller agreement, order form template, DPA pass-through clause, support SLA definition
• Setup time: 4–8 weeks of legal review

Phase 3 — SI with Managed Service (if Deloitte wants to build a practice)

Deloitte bundles SecurityV0 as "Deloitte Managed Non-Human Identity Security, powered by SecurityV0." Sold as a managed service with monthly billing.

• Deloitte discount: 30–35% off list (wholesale pricing for managed service volume)
• Partner-hosted deployment model (Deloitte operates, multi-client within Deloitte's environment)
• Deloitte manages all customer operations
• SecurityV0 receives royalty per seat/customer, no operational burden
• Requires: OEM/managed service addendum to reseller agreement

Key Contractual Points

Do not grant exclusivity. Deloitte will ask. Decline. An exclusive arrangement with a Big4 firm that has competing relationships is a trap — it locks you out of other channels while Deloitte may deprioritize your product.

Pass-through EULA. When Deloitte resells, the end customer must agree to SecurityV0's EULA directly (pass-through clause). This binds the customer to IP protection terms even when SecurityV0 is not the contracting party.

Audit rights. SecurityV0 retains the right to audit actual installations against licensed nodes. License telemetry supports this automatically for connected deployments.

Deal registration. Offer Deloitte an additional 5% margin for registering an opportunity before the sales cycle. This incentivizes active prospecting without committing to exclusivity.

No MFN (Most Favored Nation). Deloitte will ask for MFN pricing. Decline or limit to: "same tier, same minimum commitment." MFN without qualification would prevent you from offering better terms to a partner with a larger commitment.

Revenue Framing for Deloitte

Deloitte makes money from services hours, not from software margin. Frame the partnership around:

• Consulting hours enabled: SecurityV0 findings generate remediation work (ownership gap resolution, permission cleanup, accountability governance)
• New service line: "Non-Human Identity Governance Assessment" — Deloitte-branded assessment service powered by SecurityV0
• Ongoing managed service: Monthly retainer to operate SecurityV0 and report on a client's autonomous authority posture
• Regulatory response: DORA (EU financial sector), NIS2, and AI Act compliance will drive demand for exactly what SecurityV0 provides

The more SecurityV0 findings Deloitte clients have, the more consulting hours Deloitte sells to fix them. This is a structurally aligned partnership.

---

Part 7: Open Questions and Decisions Required

Question	Options	Recommended
Primary EU region	eu-west-1 (Ireland) vs. eu-central-1 (Frankfurt)	eu-west-1 — lower latency, lower cost, more services
Multi-tenant vs. single-tenant SaaS	Shared infra vs. per-client stack	Single-tenant from start — cleaner isolation, easier to sell
License management vendor	Keygen vs. Cryptlex vs. build	Keygen — best developer experience, add Cryptlex for air-gapped later
Phase 1 partnership structure	Referral vs. reseller immediately	Referral — faster to execute, prove model first
SOC 2 timeline	Start now vs. after first client	Start now — many enterprise buyers require it, takes 6–12 months
EULA: Custom vs. BSL	Custom commercial vs. Business Source License	Custom commercial — full control, simpler for enterprise legal review

---

Appendix: Deloitte FAQ Cheat Sheet

Quick reference for Deloitte team members presenting to clients:

"Where does my data go?"

If vendor-hosted: Your security metadata is processed and stored in AWS eu-west-1 (Ireland) or eu-central-1 (Frankfurt). It never leaves the EU. If you prefer your own environment, we can deploy inside Deloitte's infrastructure or directly within your network.

"Do you have GDPR documentation?"

Yes. We provide a Data Processing Agreement covering all data categories, retention periods, deletion procedures, sub-processors, and breach notification. Available on request.

"What exactly do you read from our systems?"

We read automation definitions, integration registrations, service principal metadata, role assignments, ownership information, and (for AWS) IAM and AI-agent configuration. We do not read business records, ticket content, email, files, secret values, S3 bucket contents, or any application data.

"What does the AWS integration look like?"

A read-only IAM role in your account(s), trusted by the SecurityV0 hub with a customer-set ExternalId — the same pattern as Wiz, Orca, and Datadog Cloud Security. We provide a CloudFormation template; the customer deploys it. Single-account, multi-account, and AWS Organizations org-mode are supported. No agent installed, no inbound network access. Full plain-English summary: AWS Access — Customer Summary.

"Can we run this without sending data to you?"

Yes. Both partner-hosted (within Deloitte's environment) and customer self-hosted (within the client's environment) deployment options are available. In those models, SecurityV0 infrastructure is not involved in processing your client's data.

"How long do you keep our data?"

Default is 12 months for scan results. Configurable up to 24 months. All data is deleted within 30 days of contract termination, with a signed deletion certificate provided.

"Do you have SOC 2?"

We are in the process of pursuing SOC 2 Type II. In the meantime, we are happy to complete a security questionnaire and provide our current control documentation.

---

Document owner: SecurityV0 founding team Next review: After first Deloitte partnership agreement signed