Security
How we protect client data, prevent rule-breaking, and make the work auditable.
Protocol Wealth is an SEC-registered investment adviser handling non-public personal information for ultra-high-net-worth families and institutional treasuries. The posture documented below is designed for transparency: every claim maps to a specific control we can demonstrate to clients, examiners, and the open-source community that audits our chassis code.
Last verified May 19, 2026. Reviewed and approved by Nick Rygiel, Managing Partner / CTO / CISO. See the CISO attestation at the bottom.
For the plain-English companion that explains what we mean by "substrate" and how this posture is structurally enforced, see /how-we-work. For the RIA agent substrate, see /agents.
Snapshot
At a glance
The substrate we have built — including the engineering layers most firms do not surface to public view. Each row maps to a control documented in detail below.
| Layer | What it does | Where it lives |
|---|---|---|
| Zero Data Retention (ZDR) workspace | Anthropic ZDR — contractual and enforced by the vendor at the API workspace level; our content is not retained for training | All AI-using surfaces |
Schema-level PII tagging (pii.{high,medium,low}) | Fields tagged at ingestion; high-tag fields are structurally excluded from any LLM-bound payload | pw-api + downstream BFFs |
| Independent PII egress canary | Second-layer guard at every Anthropic SDK call; pattern set deliberately re-implemented byte-identical across surfaces | pw-os-v2 + pw-portal-v2 (pw-api wave queued) |
| WORM audit retention | 7-year retention-locked Google Cloud Storage bucket mirrors the application audit log | Per SEC Rule 17a-4(b)(4) + 17a-4(f)(2)(ii) |
| Sentinel-row reconciliation | Reconciliation against immutable evidence rows emits new linked rows; never UPDATE | audit_log, KYC, e-signature archive |
| Canonical webhook receiver | Every vendor callback flows the same six stages: verify, dedup, parse, process, audit, dead-letter | All vendor integrations |
| Defense-in-depth onboarding | Veriff identity, Scorechain AML, Anvil e-signature — each via reviewed webhook handler | New-client onboarding |
| Single-cloud sovereignty | Google Cloud only (ISO 27001 / SOC 2 alignment); no multi-cloud client-data spread | All PW-internal services |
All client data ingestion, AI inference, and audit retention occurs on infrastructure located within the United States.
Architecture
System architecture (abridged)
How requests flow through the platform — from advisor or client surface through the PII guard, into the AI inference layer or the vendor webhook layer, with every state change mirrored to the WORM audit archive.
+-----------------------------------+
| pwos.app (advisor IDE) |
| pwportal.app (client portal) |
+------------------+----------------+
| HTTPS
| PII guard before every AI call
v
+-----------------------------------+
| pw-api (Cloud Run; internal) |
| schema-level PII tag gate |
+------------------+----------------+
|
+---------------+-----------+-----------+---------------+
| | | |
v v v v
+---------+ +-------------+ +--------------+ +-------------+
| Cloud | | Anthropic | | Vendor | | Vendor |
| SQL | | Claude | | webhooks | | reads |
| (app + | | ZDR | | (Veriff, | | (Quiltt, |
| audit) | | workspace | | Anvil, | | custodian, |
+----+----+ +-------------+ | Quiltt,...) | | Scorechain)|
| +------+-------+ +-------------+
v |
+-------------+ v
| GCS WORM | <-- canonical writeAuditLog()
| mirror | mirror of |
| 7-yr lock | every audit_log row |
+-------------+ |
^ |
| |
+-------------------------------------------+Principles
Our security principles
Assume every vendor is external, even the ones we trust.
Client data is minimized, redacted, or tokenized before being routed to any third-party system, including AI model providers. Vendors don't get raw client information — they get whatever minimum is required to perform the requested task.
Client data isolation is architectural, not procedural.
Tenant separation is enforced at the database boundary (row-level security plus per-route tenant guards), not just in application code. A query written by our engineers against the wrong tenant context fails before it can return data.
Every action leaves a record.
Advisor activity, system access, AI-generated analyses, vendor-doc handling, and client-facing outputs are logged with timestamp, actor, and context. Records are written by a SQL function with a non-deletable trigger; the audit archive bucket is retention-locked at 7 years per SEC Rule 17a-4.
Encryption is the default state.
All client data is encrypted at rest (Google-managed keys, AES-256) and in transit (TLS 1.2 or higher; TLS 1.3 negotiated where supported). Field-level encryption for the most sensitive identifiers is on the roadmap; keys are managed separately from infrastructure credentials.
Change Management
How we prevent the rules from being broken
Architectural controls beat written policies. Each item below is a guardrail enforced by the tooling, not a rule employees are asked to remember. If the tooling allows it, we treat it as allowed; the policies converge to what the system permits.
Branch protection on every active runtime repository
Direct pushes to main are blocked across pw-os-v2,
pw-portal-v2, pw-api, pw-infrastructure, and
pw-onchain. Required-status-checks gate merges; force-push and branch-delete are
both refused; no --no-verify or signature-bypass overrides are permitted.
Required CI gates per pull request
Type checking, unit tests, structured-log compliance lints (PII guard byte-identity check across services, Anthropic SDK wrapper enforcement, no-hardcoded-Claude-model-strings rule), CodeQL scanning, dependency vulnerability scans, and Terraform validate / fmt all run on every pull request. PRs cannot merge until every required check passes.
Infrastructure as Terraform — no console clicks
All GCP infrastructure is declared in the pw-infrastructure repository.
Production change is gated on PR review + GitHub Actions apply via Workload Identity
Federation (no service-account keys). Cloud Run env-var, IAM-binding, and bucket-policy
changes made directly via gcloud are silently reverted on the next baseline
apply — by design.
Schema migrations reviewed in PR; never auto-pushed
Database schema changes are hand-authored SQL migrations that ship in a code review. ORM-driven schema-push is forbidden. Migrations apply via a Cloud Run Job that runs once per deploy with audit logging; the Postgres instance has private-IP-only ingress so no client tooling can reach it without IAM authentication via the Cloud SQL connector.
Two-turn confirmation gates on destructive actions
Every destructive admin operation (vendor delete, vendor document delete, client portal lock or reset, vendor risk-score downgrade, AI tool that writes to Drive / Sheets / Slides / Wealthbox / Calendar) requires a two-step gate: the first call returns a server-rendered preview plus a sha256 token bound to the request payload; the second call must resubmit the same payload with the token. Constant-time comparison; payload tampering invalidates the token. Twelve consumers as of this attestation.
Secrets via Secret Manager — never in source
All production secrets live in Google Secret Manager with per-secret IAM bindings to the minimal set of service accounts that need them. Application code reads secrets at runtime via Cloud Run secret-key references; secrets never appear in environment-variable definitions, build artifacts, or container images. Pre-commit secret scanning catches accidental check-ins.
Approver separation for marketing communications
Newsletter broadcasts, webinar communications, and other materials subject to SEC Rule 206(4)-1 require a Chief Compliance Officer approval that is enforced server-side: the database constraint refuses any "approved" status transition where reviewer email equals author email. Every status transition (created, submitted, approved, rejected, sent) writes an immutable audit row.
No autonomous trade execution; AI is additive only
The platform contains no code path that places, modifies, or cancels a trade based solely on AI output. Investment decisions are made by humans; AI surfaces context, drafts artifacts, and runs research workflows — every client-facing artifact passes through human review before it leaves the firm. This is enforced by absence: the trade-execution surface simply does not exist in the codebase.
Operations
How the work is run day-to-day
Architectural controls work because the operating cadence around them is honest. The items below describe how routine work, oversight reviews, incident handling, and vendor due diligence are structured.
Compliance Hub — vendor register with SOC 2 / DPA / pen-test attachments
Every active vendor (currently 22 canonical entries seeded by terraform) carries its compliance documents on disk inside the firm-internal Compliance Hub: SOC 2 reports, DPAs, penetration tests, insurance certificates, privacy policies. Each upload runs through a structured AI extraction (advisory, not authoritative — the source PDF is the system of record) that surfaces audit period, opinion type, exception count, sub-processors, retention window, and breach-notification window. Every download is logged.
Audit-log immutability — append-only, retention-locked archive
The application audit log is append-only at the database layer (a BEFORE DELETE trigger raises on every attempted row removal). Application-level wrappers funnel every mutation through a SQL function that writes the audit row inside the same transaction as the domain change. The archive bucket holding 7-year exports is retention-locked at the GCS layer: the lock cannot be shortened, only extended, satisfying the SEC Rule 17a-4 non-rewriteable / non-erasable technical control.
Audit-anomaly detection — nightly cron + partner review
A scheduled job runs against the firm's audit log every night at 06:00 UTC and emits findings against three rules: off-hours admin activity, rapid-sequential admin actions (potential session compromise), and a new actor performing a privileged operation for the first time. Findings surface on a partner-tier review board; the review action itself writes an audit row.
Daily Cloudflare posture probe + drift detection
A daily GitHub Action sweeps Cloudflare account, zone, certificate-pack, and ruleset state and compares against a committed baseline. Any change opens a tracked issue; the snapshot is uploaded to a private GCS bucket the firm's admin surface reads to render a posture board with live wire headers, cert expiry tracking, and notification-policy fingerprints.
Domain-wide-delegation hygiene
Google Workspace Domain-Wide Delegation grants are consolidated to a single service account
([email protected]) with twelve documented OAuth
scopes — the minimum needed for advisor email search, calendar reads / writes, Drive read /
write inside scoped folders, and Workspace audit-log queries. Five legacy DWD grants from
prior migrations were removed in 2026-04 and are documented in the firm's security register.
Defense-in-depth observability
Self-hosted Langfuse (langfuse.protocolwealthllc.com) captures every Anthropic
generation with structured failure-class taxonomy and prompt-cache hit metadata. Cloud
Logging absence-of-signal alerts on every scheduler tick (Cloud Scheduler outbound 401s went
silent for 11 days in April; the alerting layer added in response now catches that class of
failure within an hour). Frontend error boundaries log to Cloud Logging on every uncaught
render error.
Incident response cadence
The firm's incident response plan (cross-referenced from shared/docs/compliance/incident-response-plan.md)
defines triage tiers, containment protocols, regulator-notification paths, and post-incident
review ownership. Detection runbook includes Cloud Logging filters, audit-log search queries,
and contact rotation. Reg S-P breach notification follows the deadlines set by the rule —
internal "30-day" service goals do not override the legally required clock.
Stack
The stack — current state
Production runtime is Google Cloud (single org, single primary region us-central1)
behind Cloudflare. Each vendor is subject to a Data Protection Agreement and is selected for
compatibility with our obligations under SEC Rule 204-2 and Regulation S-P. Last refreshed
May 19, 2026; legacy entries (Fly.io, Neon, Upstash) are no longer in the runtime
path.
Google Cloud Run
All application services run on Cloud Run in us-central1. Each service has a
dedicated service account, a private VPC egress path, scoped Secret Manager access, and
ingress restricted to internal-only or authenticated public depending on role. Backend
services (pw-api, pw-api-webhooks) are
INGRESS_INTERNAL_ONLY; frontends (pw-os, pw-portal)
are public-internet but Cloudflare-fronted.
Google Cloud SQL (Postgres 16)
Highly-available primary instance hosting two databases: pw-core (client,
advisory, audit, compliance) and pw-data (market data, reference data). Private
IP only; no public ingress. IAM authentication via the Cloud SQL connector — no static
database passwords. Per-tenant separation enforced at the row-level. Automated backups +
point-in-time recovery on the regulated database.
Google Memorystore (Redis 7)
Standard-HA Redis instance for session state, vendor-API read-through cache, and per-message PII manifest storage. TLS in transit, AUTH required, private IP only. Cache keys are statically validated to refuse client-identifying patterns; no client PII reaches the cache.
Google Cloud Storage
Buckets for chat attachments, vendor compliance documents, and the SEC Rule 17a-4 audit archive. The audit-archive bucket is retention-locked at 7 years (the lock cannot be shortened, only extended). Public-access prevention enforced; uniform bucket-level access on every regulated bucket; access logs captured in Cloud Audit Logs.
Workload Identity Federation
GitHub Actions deploys are authenticated to GCP via Workload Identity Federation, attribute- gated to the Protocol-Wealth GitHub organization and a pinned list of repositories. No service-account JSON keys exist in the firm. Local development uses short-lived OAuth tokens issued to individual humans, never long-lived credentials.
Cloud Audit Logs (org-wide)
Org-wide Data Access logging captures every read/write against every Google API at the project level. Logs sink to a BigQuery dataset (1-year queryable) and a separate GCS archive (7-year retention, lock-locked). This is the primary forensic trail when application audit alone is insufficient.
Cloudflare
DNS, edge security, marketing-site delivery (Cloudflare Pages), and bot challenge for the
public surface. The authenticated platform domains (pwos.app,
pwportal.app) are intentionally DNS-only on Cloudflare; security headers come
from the application layer (HSTS preload, strict CSP, X-Frame-Options, X-Content-Type-Options,
Referrer-Policy) rather than the CF dashboard, with a daily probe reconciling against a
committed posture baseline.
Google Workspace (Enterprise Plus)
Email, document storage, identity (Google SSO with enforced 2FA on every advisor account),
and compliance retention via Vault. Workspace domain restriction is enforced for advisor
authentication on the pwos.app surface — only @protocolwealthllc.com
accounts can sign in. The Reports API and Drive Activity API are wired for compliance/eDiscovery
workflows.
Postmark
Transactional email delivery for assessment results, client notifications, broadcast sends, and operational alerts. TLS in transit, message archive consistent with retention requirements. Inbound parse webhook (HMAC-verified) feeds the firm's inbox triage surface.
Hadrius
Compliance-AI archive for social media, marketing communications, and other advertising records required under Marketing Rule 206(4)-1 and Rule 204-2.
Scorechain (via QuickNode) + Veriff
Wallet sanctions screening (Know-Your-Wallet) via Scorechain's risk-assessment API behind QuickNode. Identity verification (Know-Your-Customer) via Veriff with HMAC-verified webhooks. Both services receive only the data needed to perform the check; results cache locally with configurable TTL and an explicit re-check escape hatch.
Quiltt
Custodian aggregation (brokerage, banking, credit). Read-only OAuth-style connections that clients initiate from the portal. The platform brokers Quiltt sessions through an internal service and never holds custodian credentials directly.
Turnkey + Fordefi
Client wallet custody is non-custodial: keys are held by the client via Turnkey passkey-based authentication (client-as-sole-root). Firm-owned treasury operations use Fordefi MPC for transaction signing. Protocol Wealth never sees client private keys.
ChainDeploy
Onchain deployment + verification infrastructure for the firm's vault and strategy contracts. All contracts are reviewed in code, deployed via Workload Identity-authenticated CI, and source-verified on the deployed chain so that clients and counterparties can independently audit byte-for-byte equivalence with the public repository.
Anthropic (ZDR, US-only)
Primary AI model provider (Claude family). Protocol Wealth is enrolled in Anthropic's Zero Data Retention program — model traffic is not persisted, retained, or used for training. Workspace ID is asserted on every API call at boot and logged in our audit trail. All inference endpoints route through US-only data residency. Client non-public personal information is redacted or tokenized before the request leaves firm infrastructure; see the AI-specific protections section below.
Self-hosted Langfuse
AI observability runs on a self-hosted Langfuse instance at
langfuse.protocolwealthllc.com (deployed inside the firm's GCP project). Every
advisor chat turn produces a generation trace with token counts, model id, prompt-cache
metadata, and a failure-class taxonomy. AI traces never leave firm infrastructure.
All vendors above are US-based with data residency in US regions. The full subprocessor list and per-vendor data flows are documented in our Privacy Policy. We do not currently handle protected health information (PHI); the architecture is designed so formal Business Associate Agreements can be executed if and when that capability is added.
Vendor due diligence
Current active vendor roster
Every subprocessor passes through a documented due-diligence framework aligned to Reg S-P §248.30 vendor management expectations. SOC 2 reports, DPA executions, and (where applicable) penetration-test reports are collected on file; vendor risk assessments refresh annually and on material change.
| Vendor | Role | Attestations on file |
|---|---|---|
| Anthropic, PBC | AI inference under ZDR | SOC 2 Type II, ISO 27001 |
| Google Cloud Platform | Compute, storage, secrets, audit logs | SOC 1/2/3, ISO 27001/27017/27018/27701, PCI DSS, FedRAMP High |
| Cloudflare | DNS, CDN, WAF for public surfaces | SOC 2 Type II, ISO 27001 |
| Veriff OU | Identity verification (KYC) | SOC 2 Type II, ISO 27001 |
| Scorechain S.A.S. (via QuickNode) | OFAC sanctions screening + KYT risk scoring | Under active vendor-risk review |
| QuickNode, Inc. | Multi-chain RPC + Scorechain integration substrate | SOC 2 Type II |
| Hadrius, Inc. | AI compliance monitoring + supervision | Under active vendor-risk review |
| Quiltt, Inc. (with MX, FinGoal) | Financial account aggregation | SOC 2 Type II |
| Altruist Financial LLC | Advisory custodian + billing | SEC/FINRA oversight, SOC 2 Type II |
| Interactive Brokers LLC | Brokerage + custody | SEC/FINRA registered broker-dealer |
| Anchorage Digital Bank, NA | Qualified digital asset custodian | OCC oversight, SOC 2 Type II |
| BitGo Trust Company | Qualified digital asset custodian | SD Banking oversight, SOC 2 Type II |
| Fordefi | MPC wallet infrastructure | SOC 2 Type II |
| Anvil | E-signature with ESIGN/UETA attestation + PDF/A archival | Vendor DD on file |
| Postmark | Transactional email | SOC 2 Type II |
| Wealthbox | CRM | SOC 2 Type II |
All vendor relationships carry contractual restrictions on data use, breach-notification clauses (72-hour closure where applicable), and US-region processing commitments. Authenticated advisory surfaces do not transit Cloudflare; the public-edge layer handles marketing properties only.
Access
Advisor authentication and access
Advisor access to the firm-internal platform requires:
-
Google SSO restricted to the
protocolwealthllc.comWorkspace domain; two-factor authentication enforced at the Workspace level - Role-based access control inside the platform (advisor, partner, employee tiers); session JWT carries the role claim and routes are gated server-side
- 15-minute session lifetime with refresh-on-activity; idle sessions auto-terminate
- Per-operation confirmation gate on destructive admin actions (vendor deletes, portal locks, risk-score downgrades, AI tool writes to Drive/Sheets/Slides/Wealthbox)
Client authentication on the portal
Clients sign in to pwportal.app via Google OAuth XOR a passkey (each client picks
one factor at first signup; passkey users carry a PIN as inherent two-factor). Multiple passkeys
per client are supported for device redundancy. Turnkey is never a 2FA factor for portal sign-in
— Turnkey itself requires login first, so it cannot bootstrap that path.
AI Governance
AI-specific protections
Where client data is routed to AI models for analysis, the platform applies a four-layer PII
pipeline (regex pattern matchers + financial-recognizer overlays + a configurable allow-list +
an injection-detector boundary check) before any external API call. Detected entities are
substituted with <TYPE_N> placeholders that survive the round-trip; the
response stream is rehydrated back to the original values only after returning to firm
infrastructure. The redaction manifest itself is held in encrypted Memorystore for the
conversation lifetime.
Anthropic is enrolled in Zero Data Retention; inference traffic is US-region only. Workspace identity is asserted at process start so a credential rotation that would route requests to a non-ZDR organization fails fast. Per-message audit rows record the prompt hash, response hash, model id, and Langfuse trace id — never raw content — so the audit trail can never become a correlation oracle on PII.
Prompt caching is enabled on the chat surface's system prompt + tool definition prefix. Subsequent advisor turns hitting the same prefix pay 10% of the normal input rate (Anthropic's ephemeral-cache pricing). Cache hit metadata is recorded in Langfuse for observability; no client content sits inside the cached prefix.
The platform does not use AI to execute trades, open accounts, modify client positions, or authorize any irreversible action. Every AI-generated artifact that would surface to a client passes through Chief Compliance Officer review under the firm's Marketing Rule 206(4)-1 workflow.
Public-facing OSS chassis: the PII guard, audit-log helpers, and core model-call wrappers are published in our open-source repositories so that other RIAs, researchers, and clients can audit them. See our open-source page for current repository links.
Frameworks
Mapping to ISO 27001 + SOC 2
Protocol Wealth is not yet ISO 27001 or SOC 2 audited; we are an early-stage SEC RIA. The controls table below maps the architectural posture documented above to the relevant ISO 27001 Annex A control families and SOC 2 Trust Services Criteria so prospective clients, partners, and an eventual auditor can locate each control.
| Control area | ISO 27001 Annex A | SOC 2 (TSC) | Where it lives |
|---|---|---|---|
| Identity + access control | A.5.15 – A.5.18, A.8.2 – A.8.5 | CC6.1, CC6.2, CC6.3 | Workspace SSO + 2FA, role-based gates, 15-min sessions, confirm gates |
| Encryption (at rest + in transit) | A.8.24, A.8.20 | CC6.7 | AES-256 GCP-managed keys; TLS 1.2+; HSTS preload |
| Audit logging + monitoring | A.8.15, A.8.16 | CC7.2, CC7.3, CC4.1 | Append-only audit_log + 7-yr retention-locked GCS archive + Cloud Audit Logs |
| Change management | A.8.32, A.8.31 | CC8.1 | Branch protection, required CI gates, terraform-only infra, no console clicks |
| Vulnerability + dependency management | A.8.8 | CC7.1 | CodeQL on every PR; Dependabot; Trivy IaC + filesystem scans on every push |
| Vendor / supplier oversight | A.5.19 – A.5.22 | CC9.2 | Compliance Hub vendor register + SOC 2 / DPA / pen-test attachments + AI extraction |
| Cryptographic key management | A.8.24 | CC6.7 | Secret Manager with per-secret IAM bindings; no service-account JSON keys (WIF only) |
| Network segmentation | A.8.22 | CC6.6 | VPC + private-IP-only DB / Redis; INTERNAL_ONLY ingress on backend services |
| Information classification + handling (PII) | A.5.12, A.5.13 | P (Privacy) — P3.2, P4.2 | PII Contract #3 (byte-identical scrubber across pw-os-v2 / pw-portal-v2 / pw-api), placeholder rehydration |
| Incident management | A.5.24 – A.5.27 | CC7.4, CC7.5 | Documented IRP, audit-anomaly cron, Reg S-P breach-notification timeline integration |
| Backup + recovery | A.8.13 | A1.2, A1.3 | Cloud SQL automated backups + PITR; quarterly BCP / PITR drill on calendar |
| Records retention (regulated) | A.5.34 | CC7.3 (records) | SEC Rule 17a-4 satisfied via retention-locked GCS audit archive (7-year, lock cannot be shortened) |
The firm has not yet engaged an external auditor for either ISO 27001 or SOC 2 attestation; this mapping is an internal self-assessment provided for transparency. We expect to begin a SOC 2 Type I scoping engagement in the next twelve months.
Verify, don't trust
Public source code
Several core security primitives — the PII guard, audit-log helpers, the AI model-call wrapper, and our chassis layout — are published as open-source repositories. We publish them so clients, partners, security researchers, and other RIAs can audit them, find weaknesses, and propose improvements.
- pwos-core — operating-system chassis: PII guard, audit log helpers, JWT session, role guards
- nexus-core — analytical surface chassis: market data adapters, EMF framework primitives
-
Each repository carries its own
SECURITY.mdwith the responsible-disclosure policy and reporting contact
More context, including how to read the code without running it, is on our open-source page.
Contact
Reporting a security concern
If you suspect unauthorized access to your account
Contact your advisor immediately and email [email protected]. We acknowledge unauthorized-access reports out of band; do not wait for the platform to confirm.
If you've found a potential security issue with our platform
Email [email protected]. We aim to acknowledge reports within 48 hours and respond substantively within 5 business days, consistent with our obligations as an SEC-registered investment adviser. PGP key available on request.
If you're a security researcher
The responsible-disclosure policy is in each repository's SECURITY.md at
github.com/Protocol-Wealth.
We do not currently run a paid bounty program but credit researchers in the relevant repo's
SECURITY.md when patches land.
RFC 9116 security.txt
Machine-readable contact + policy at /.well-known/security.txt.
Verify, don't trust
How to verify any of this
We encourage qualified prospects, partners, and reviewers to verify our posture rather than accept it at face value.
Confirm ZDR with Anthropic
Our workspace ZDR status (effective April 21, 2026; workspace ID asserted at process start) is attestable by Anthropic on request to an appropriately credentialed reviewer under NDA.
Review the substrate
Architecture Decision Records covering PII tagging, the WORM audit mirror, and the webhook receiver primitive are available for review by qualified institutional prospects under NDA. Public high-level summaries live on this page.
Sample audit log + WORM mirror
Representative anonymized samples of audit-log rows demonstrating action verb structure, principal chain capture, and WORM-mirror round-trip are available for institutional due-diligence reviewers.
Vendor DD bundle
SOC 2 reports, DPAs, and vendor risk assessments are available under NDA for qualified institutional prospects.
Written attestation
A formal written attestation of current AI posture (subprocessor list, ZDR status, inference region, PII controls in effect at time of request) is available on letterhead from the CCO on qualified request.
Form ADV Part 2A
Public at adviserinfo.sec.gov/firm/brochure/335298.
Commitments
If something goes wrong
- We will detect and respond quickly. Continuous monitoring, automated alerting on the egress canary and audit-mirror substrate, and documented incident response procedures.
- We will notify affected clients within 30 days if sensitive information is compromised, consistent with amended SEC Regulation S-P.
- We will conduct post-incident review and share relevant findings where appropriate.
- We will honor data-rights requests (access, correction, deletion, portability) subject to our regulatory record-retention obligations.
Ongoing investment
Forward cadence
- Quarterly internal security reviews
- Quarterly ZDR configuration audit (next: July 21, 2026)
- Quarterly tabletop incident response exercises (started Q2 2026)
- Annual vendor security re-reviews
- Periodic external penetration testing (formal engagement planned for 2026)
- SOC 2 Type I readiness targeted for Q4 2026; Type II attestation on a 2027 timeline
- BlockSkunk Phase 0/1 (ISO 27001 + SOC 2 alignment + GCP environment review) engaged and underway
Attestation
CISO sign-off
I have reviewed the controls described on this page as of May 19, 2026 and confirm that each control is in place at the firm and reflects how Protocol Wealth operates today. The mapping to ISO 27001 Annex A and SOC 2 Trust Services Criteria represents an internal self-assessment; the firm has not yet engaged an external auditor for an attestation engagement against either framework.
Protocol Wealth's posture is documented to be auditable: every control above can be traced to specific terraform, application code, audit-log row, or open-source repository. Discrepancies between this page and the runtime system are bugs in this page; please report them via the channels in the Reporting a security concern section.
Nick Rygiel
Managing Partner / CTO / CISO
Protocol Wealth, LLC · CRD #335298
Last updated: May 19, 2026. Protocol Wealth LLC is an SEC-registered investment adviser (CRD #335298). Full regulatory disclosures are in our Form ADV Part 2A and 2B.
Registration with the SEC does not imply a certain level of skill or training. This page describes the controls in place as of the date above and is provided for informational purposes; it does not create additional contractual obligations beyond those set out in our advisory agreements, Privacy Policy, and Terms of Service.
Response-time targets (48 hours for acknowledgement, 5 business days for substantive response) are internal service goals, not guarantees. Legally required notifications — including breach notifications under Regulation S-P — follow the deadlines set by the applicable rule, not the internal targets.
The ISO 27001 and SOC 2 mapping in this document is an internal self-assessment. Protocol Wealth has not been audited against either framework as of the sign-off date. Statements about external auditor engagements are forward-looking and subject to change.