Paridity - standardized security questionnaire responses¶
Verified data. Trusted outcomes.
How to read this. Paridity's primary security story is secure by design - see the Trust & Security overview. This document is a reference for teams that must map Paridity to a SIG Lite / CAIQ questionnaire. Because Paridity is customer-hosted and stores no customer data, many rows are legitimately "not applicable" - that is the design working as intended, not a gap. Formal certifications (SOC 2 / ISO) are addressed as applicability, not a roadmap.
CDC-Aware Reconciliation Platform
How to read this document¶
Enterprises send Paridity standardized vendor-risk questionnaires (SIG Lite, CAIQ, or house variants). This document pre-answers the recurring questions, organized by the common framework domains, so a security review can start from written, sourced positions rather than a blank form.
One structural fact answers a large share of the questions up front. In Paridity's current shipping architecture, the entire platform - API, UI, Temporal orchestration, all workers, and the PostgreSQL evidence store - deploys inside the customer's own cloud account/VPC, via a Helm chart and Terraform modules the customer controls. Paridity, the vendor, operates no infrastructure that holds or processes customer data (its one operated service is the licence service, which receives licence data only: the licence key, a machine id derived from a random installation id, the activation id, the product name, and the platform and architecture) and has no network path to a customer's credentials, schema/object names, or evidence values. Many control questions ("where is our data stored?", "who at the vendor can access it?", "what happens if the vendor is breached?") therefore have a structural answer: customer data never leaves the customer's environment, and there is no Paridity-operated environment holding it. Where a control is not in place (e.g. SOC 2, an independent penetration test, cyber insurance), this document says so plainly - per Paridity's own documentation standard, an unverified claim is never stated as fact.
Status vocabulary (used throughout, per the Paridity style guide):
| Status | Meaning |
|---|---|
| Verified | Implemented and validated end-to-end, with evidence traced to code or live test. |
| Supported | Implemented and operational; broader live verification still expanding. |
| Roadmap | Planned; not yet built or not yet validated - never presented as shipped. |
| Evaluating | Candidate under consideration; no committed implementation. |
All answers describe the shipping, customer-hosted architecture - the entire platform runs inside the customer's own cloud account. A hosted deployment option is on our internal roadmap with no committed date; it changes none of the answers below.
1. Governance, risk & compliance (GRC)¶
| # | Question (typical SIG Lite / CAIQ phrasing) | Paridity response | Status |
|---|---|---|---|
| GRC-1 | Do you hold a SOC 2 Type II report or ISO 27001 certification? | No. EGMW holds no SOC 2 report or ISO 27001 certification, and no such audit is planned now or in the immediate future. The reason is applicability: these attest a service organization's controls over the customer data it hosts or processes. Paridity is software the customer runs in its own environment; EGMW does not host it and does not process customer data (its one operated service, the licence service, receives licence data only - see SUB-2). The controls that matter for the deployment - access, encryption, backup, network, monitoring - are the customer's, configured inside the customer's own cloud account and covered by the customer's existing certifications and audits. (Security Whitepaper, "Limitations & roadmap honesty".) | See response (no certification, none planned) |
| GRC-2 | Do you have a documented information-security policy program? | No formal program. EGMW is a small business and has no formal, documented information-security program or published information-security policy set today. What exists: a governance documentation practice (documentation register, style guide with binding no-over-claim rules, classification scheme: Public / Customer Confidential / Under NDA / Paridity Internal), an Acceptable Use Policy, an open-source software policy (draft), a coordinated vulnerability-disclosure policy (SECURITY.md), and the automated security gates in AIS-4. |
See response (no formal program) |
| GRC-3 | Is your product suitable for SOX/ICFR-relevant processes? | Yes - this is the product's design center. Every run produces an append-only, tamper-evident audit trail: config fingerprint (config_checksum) written before any comparison, immutable compare_started_at audit anchor, per-phase timings with worker identity, hash-chained cfg.audit_log, and cryptographically signed, hash-chained evidence bundles an auditor can verify offline with the customer-held signing key and the shipped fail-closed verifier. (Audit & compliance proof doc.) |
Verified |
| GRC-4 | Does AI play any role in your control outcomes? | AI in Paridity assists triage and explanation only - it never determines whether data matches. Correctness is always established by the deterministic hash_total / row_hash / field_diff pipeline. AI never writes to evidence (ev.*) or the audit log, and never auto-confirms an operator action. |
Verified |
| GRC-5 | Do you perform background checks and security-awareness training for personnel with access to customer data? | Structurally, no Paridity personnel have access to customer data - there is no vendor-side environment holding it, and no vendor network path into the customer VPC. EGMW has no formal, documented background-check or security-awareness training program. | See response |
| GRC-6 | Who is the contracting legal entity? | Evil Genius MindWorks LLC (Paridity is the product name). Contract paper: MSA with Schedules A-D, including a Security Overview (Schedule C) and a Data Processing Addendum (Schedule D) drafted for this architecture. | See response |
| GRC-7 | Could a privileged user manipulate reconciliation outcomes without detection? | Paridity scopes this explicitly rather than claiming blanket tamper-resistance. The proof's hash_total aggregate defends against replication faults and corruption (quantified collision bound ≈10⁻¹⁹ per comparison); it is not designed to resist an insider who can deliberately write compensating changes into the databases being compared - no SQL-computable aggregate is, and Paridity says so in its accuracy proof (Threat model section) instead of implying otherwise. That insider case is an access-control and audit problem, covered by: the customer's own database access controls and change auditing on source/target; Paridity's append-only evidence, hash-chained + checkpoint-signed audit log (checkpoints externally anchorable to WORM storage / RFC 3161 TSA / SIEM), and signed evidence bundles verifiable offline with the customer-held key (past results cannot be silently rewritten); and four-role RBAC with actor/IP attribution on every admin action. |
Verified (scoping documented) |
| GRC-8 | Do you carry cyber-liability insurance? Provide a certificate of insurance. | No. EGMW holds no cyber-insurance policy and cannot provide a certificate of insurance at this time. If a customer contract requires coverage, EGMW will review the requirement. | See response (no coverage) |
| GRC-9 | Describe your company's financial viability. What happens to us if you cease operating? | EGMW is a small, privately held business; it publishes no formal viability statement and no financial statements. The mitigant is architectural: Paridity runs entirely in the customer's environment, and its only runtime dependency on EGMW is the licence service. If that service becomes unreachable - including if EGMW stopped operating it - the installation runs normally for 7 days on its last signed licence token; after that a paid licence is degraded until a refresh succeeds: runs continue and are never stopped, but they are proof-only (counts and hash totals, no field-level diffs) and bringing new configuration into service (for example, creating or enabling a mapping or schedule) is refused. No data is touched. The risk, stated: if the licence service never returns, that degraded state is permanent. No source-code escrow, perpetual-licence fallback, or offline activation path exists today. | See response |
2. Identity & access management (IAM)¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| IAM-1 | How are users authenticated? | Interactive users sign in through your identity provider over SAML 2.0 or OIDC (IAM-2). All user-facing API endpoints then require an OIDC/JWT bearer token. Bearer-token validation enforces RS256/ES256 signature algorithms only (no alg=none) and verifies aud, iss, and expiry before any request is authenticated. SCIM endpoints require their own dedicated audience and the /mcp agent surface another, applied per path, so a user token cannot drive SCIM or /mcp and vice versa. |
Verified |
| IAM-2 | Do you support SSO with our identity provider? | Yes - two interactive browser sign-in paths. SAML 2.0: Okta and Microsoft Entra ID are both live-verified. OIDC (since v1.4.0): a server-side authorization-code flow with PKCE - the client secret is resolved from your own secrets backend and the ID token must be signed with RS256, PS256, or ES256; live-verified with Microsoft Entra ID, not yet live-tested with Okta. Separately, OIDC bearer tokens from a registered per-tenant issuer are validated for API and service-account access. Identity federates against the customer's own IdP - Paridity is not in the credential path. |
Verified (SAML: Okta, Entra; OIDC: Entra); Supported (OIDC: other providers) |
| IAM-3 | Do you support automated provisioning/deprovisioning (SCIM)? | Yes - SCIM user/group provisioning is live-verified end-to-end with IdP-pushed provisioning from Microsoft Entra ID: create, update, and deprovision cycles, including hardening against Entra sending the active flag as a string (which would otherwise have bypassed deprovisioning). |
Verified |
| IAM-4 | Is role-based access control enforced? | Yes. Four roles in a strict hierarchy: platform_admin > operator > analyst > auditor, enforced in the API layer. Access is further narrowed by grants that bind a principal to specific resources (e.g. a business domain), not just a role. |
Verified |
| IAM-5 | Are privileged/administrative actions logged? | Yes. Admin-sensitive actions (e.g. bypass_readiness: true on run creation, cancellations, retention purges) require platform_admin and are written to cfg.audit_log with actor, entity, action, timestamp, and actor_ip (from X-Forwarded-For or direct connection). The audit log itself is hash-chained for tamper-evidence (§4). |
Verified |
| IAM-6 | Are there any non-SSO backdoors or development bypasses? | A development-only authentication bypass exists for local use and is production-guarded: the platform refuses to honor it outside a development/test environment, and even then only when no credentials are supplied at all - a presented token is always validated normally so RBAC still applies. Additionally, the login page hides local credentials when SSO is required. | Verified |
| IAM-7 | Can vendor staff access our production instance? | No standing access exists. The deployment runs in the customer's cloud account under the customer's IAM; any Paridity support access is access the customer explicitly provisions in their own environment, on their terms, and can revoke unilaterally. | Verified (structural) |
3. Data security & privacy¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| DSP-1 | Where is our data stored and processed? | Entirely inside your own cloud account/VPC. Source/target row data is read in-VPC by your Paridity workers; evidence (hash_total, row_hash, field_diff), metadata (object/schema/column names, config), and the audit trail all live in your own PostgreSQL instance in your account. No customer data class leaves the customer VPC. Two things can leave, neither of them customer data: the licence check to EGMW's licence service (licence data only), and a support diagnostic bundle, only if your operator downloads it and emails it to support (redacted: no column names, evidence values, hashes, connection references, secrets, or SQL; object names tokenized unless the operator opts in). (Data-Flow Disclosure §2.) |
Verified |
| DSP-2 | Is data encrypted in transit and at rest? | Connector transport to source/target databases is fail-closed in the product itself: PostgreSQL connections enforce TLS (require or stricter) by default with plaintext requiring an explicit operator opt-out, and MySQL mirrors the same fail-closed posture including defense against driver-level TLS downgrade. Ingress TLS for UI/API and managed-Postgres storage encryption (customer-managed keys available) are deployment-configuration requirements verified at install time (Terraform/Helm defaults + checklist) - stated honestly, the enforcement point for those is the customer's own cloud provider, because the stack runs in the customer's account. |
Verified (connector transport defaults); Supported (platform TLS/at-rest via deployment checklist) |
| DSP-3 | Can sensitive field values be prevented from being stored or displayed? | Yes - masking is a chained policy, not a single toggle. store_raw_diff_values is an AND-chain across tenant (L2), mapping (L4), and field (L5): any layer set FALSE suppresses raw-value storage entirely (row written with NULL values, values_masked = TRUE). mask_in_ui is a per-field display mask: set TRUE on a field and display is masked even where values are stored (a tenant-wide display-mask policy is not currently offered). Evidence endpoints apply masking at query time; a masked field never returns raw values regardless of caller role. |
Verified |
| DSP-4 | Is evidence protected against tampering? | ev.* evidence tables are append-only (two narrow, documented lifecycle exceptions; core evidence columns immutable). The one deletion path - retention purge - writes an audit record before each delete. Evidence bundles carry a SHA-256 content_hash, a previous_bundle_hash chaining each bundle to the prior one, and a detached signature over exactly the bytes that ship - verifiable offline with the shipped fail-closed verification tool (an unsigned, tampered, or wrong-key bundle never reports as verified). The signing key is the customer's choice: a KMS-backed key (AWS KMS, Azure Key Vault, GCP KMS) or a local ECDSA key signs asymmetrically, so an outside auditor verifies with the public key alone - no customer secret, no platform access, no packages (live-verified end-to-end against AWS KMS on 2026-08-28, including credential-less verification and can-fail legs; Azure/GCP use the same live-verified signer adapters); an HMAC key (customer-held) remains available. Period exports are signed containers over individually signed run bundles. Separately, the audit log's sealed checkpoints use the same asymmetric signers and can be anchored to external WORM storage, an RFC 3161 timestamp authority, and your SIEM. |
Verified |
| DSP-5 | How is data retention and deletion handled? | Retention periods are policy-resolved per mapping (retain_*_days, mapping value cannot go below the tenant minimum), with evidence-bundle containers governed separately by bundle_retention_days (tenant value, platform floor). The retention purge is the sole sanctioned deletion path for evidence and logs each deletion (table, mapping, row count, cutoff, policy) to cfg.audit_log before deleting; where a bundle's bytes live in the customer's own object store, the purge records the store's answer per object (deleted / retained by the store / already absent) rather than presuming removal. The purge runs on a built-in schedule that is default-on and dry-run-first, with pause and resume audited. An approval-gated legal hold placed on a tenant, mapping, or bundle freezes the affected evidence from purge; the purge skips it and audits the skip, and placing or releasing a hold requires the evidence.legal_hold permission and is itself audited. Because all data resides in the customer's own database, end-of-contract deletion is under the customer's direct control - decommissioning the deployment removes everything; there is no vendor-side copy to chase. |
Verified |
| DSP-6 | Do you process personal data as a processor? What about GDPR/data residency? | Paridity (the vendor) holds no customer data of any class - source data, evidence, metadata, and credentials all remain in the customer's environment - so there is no vendor-side processing of customer personal data in the core product. Data residency is wherever the customer deploys. EGMW does receive a small amount of non-customer data through its two sub-processors (SUB-2): licence data, including the request's source IP address, on the licence service, and whatever an operator chooses to send to the support mailbox. The optional AI features are bring-your-own-key: masked, name-scrubbed prompt context goes to the model provider the customer configures and contracts with directly (with a data-residency provider restriction available) - there is no Paridity-provided default provider, so the AI path adds no Paridity sub-processor. If you additionally enable the MCP agent surface, your own agent becomes an egress path to a model you chose - see SUB-5 for what it exposes and why object-name masking is best-effort there. | Verified (structural) |
| DSP-7 | Are encrypted database columns handled safely? | Where a source/target column is itself encrypted (e.g. Oracle TDE), a per-field decrypt_expression is injected into generated SQL at query time only; keys are resolved via SecretsClient and decrypted values are never persisted outside the normal evidence-masking rules. |
Verified |
4. Application & infrastructure security¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| AIS-1 | Describe your deployment/hosting model. | Single-tenant: the full stack runs in the customer's VPC - control plane, UI, orchestrator, all workers, and one PostgreSQL instance. Deployed via the Paridity Helm chart and Terraform reference modules for AWS/Azure/GCP that provision the cluster, managed Postgres with backups/PITR, the customer's secret backend, and an egress-locked network (node egress deny-by-default; cloud services reached over private paths - AWS PrivateLink VPC endpoints, GCP Private Google Access, Azure NSG service tags - with only the operator's declared endpoints allowed outbound; the licence check to EGMW's licence service needs the customer's HTTPS egress proxy, which neither the chart nor the Terraform modules open by default). The packaging is delivered and CI-gated, and the egress lockdown is verified live on all three clouds (August 2026) by a from-empty deployment plus a probe instance confirming that a non-declared destination is refused outbound - with the documented operational consequence that workloads must be pulled from a private registry or declared endpoint (public registries are refused by design). A hosted deployment option is on our internal roadmap with no committed date; its design already enforces, in review, the same invariant - credentials, object/schema/column names, and evidence values never reach Paridity-operated infrastructure. | Verified |
| AIS-2 | How are credentials to our source/target systems managed? | Paridity never stores credentials. cfg.systems.connection_ref is always a URI pointer (e.g. aws-secrets://…, azure-keyvault://…), never a secret. A SecretsClient resolves the pointer at runtime against the customer's own configured backend: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or Infisical (self-hosted, MIT). HashiCorp Vault is supported as an optional adapter for existing Vault customers only - never a default or required component. |
Verified |
| AIS-3 | How is tenant isolation enforced? | Primary enforcement: every tenant-scoped table carries tenant_id and every application query filters by it. Defense-in-depth backstop: PostgreSQL row-level security is live - 30+ tables carry a policy that fails closed to zero rows if the session tenant context is unset. Stated honestly: the application's database role currently retains an RLS bypass, so RLS today is a backstop against a missing tenant predicate, not the primary mechanism; binding the owner role with FORCE ROW LEVEL SECURITY is intentionally deferred pending a full call-site audit. Note also that deployments are single-tenant per instance, which makes cross-tenant exposure structurally impossible at the deployment boundary. |
Supported (RLS backstop); Verified (app-layer predicate) |
| AIS-4 | Do you perform static analysis / dependency scanning in your pipeline? | Yes: on every code change CI runs a blocking Semgrep gate (including SQL-injection-focused rules for dynamic SQL, with a documented, reviewed suppression convention), Python dependency auditing (pip-audit against the pinned requirements-ci.lock), npm audit on production frontend dependencies, a full-history secret scan (Gitleaks), a configuration scan (Trivy), and dependency-license gates. Production images are Trivy-scanned for fixable HIGH/CRITICAL vulnerabilities before release, and the latest release's images are re-scanned weekly. A weekly OWASP ZAP dynamic scan (DAST) runs against a CI-built stack (IRV-1). Migrations are additionally gated by a fresh-database apply job. |
Supported |
| AIS-5 | Are health/monitoring endpoints safe? | /health performs no queries against evidence tables and no cross-system checks - liveness is process-responding, readiness is DB-pool-initialized. Optional OpenTelemetry telemetry goes to the customer's own observability stack; span attributes never include row values. |
Verified |
| AIS-6 | What happens to our security posture if Paridity (the vendor) is breached? | There is no Paridity-operated environment holding customer data, no Paridity store of customer credentials, and no Paridity-held copy of customer data - a vendor-side compromise has no path to customer data or customer environments. The one Paridity-operated service is the licence service: it holds licence keys, machine ids, and the source addresses of licence requests, and your installation accepts only tokens signed by a key whose public half is built into the release image (a release constant, not a runtime setting). It has no path into your environment: your installation calls it, never the reverse, and nothing it returns is executed. Its compromise could at worst withdraw or misstate licences: an unreachable or refusing licence service moves a paid licence to proof-only and never stops runs, but a forged token claiming an expired trial licence would suspend new runs until a correct token is issued. It cannot read or change your data, evidence, or configuration. Software supply-chain integrity (the artifacts you deploy) remains the relevant surface; see §7. | Verified (structural) |
5. Data center / hosting & sub-processors¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| SUB-1 | List your data centers and hosting providers. | Paridity operates no data centers and no hosted production infrastructure for the product. The product runs in your cloud account (AWS, Azure, or GCP - your choice, via the provided Terraform modules); your cloud provider is your own infrastructure, not a Paridity sub-processor. EGMW's own hosting is limited to two services that receive no customer data from the product: the licence service, hosted on Railway, and the support mailbox, hosted on Microsoft 365 (SUB-2). | Verified |
| SUB-2 | Provide your sub-processor list. | None for customer data; two for licence and support data. No customer source data, schema/object names, or evidence values reach EGMW or any third party. EGMW uses two sub-processors for other data: (1) Railway hosts EGMW's licence service and so receives licence data (licence key, machine id, activation id, product, platform, architecture, and the request's source IP address), plus the licence and customer record EGMW holds there; (2) Microsoft 365 hosts EGMW's support mailbox, [email protected], and receives only what an operator chooses to email - the prefilled draft names the tenant, Paridity version, page, and where relevant a run id, and an attached diagnostic bundle is redacted (no column names, evidence values, hashes, connection references, secrets, or SQL; object names tokenized unless the operator opts in). The product sends no email through EGMW: notifications use only the providers the customer configures (its own SMTP server or Microsoft 365 mailbox, Slack, Teams, PagerDuty, Jira, ServiceNow, webhook). The optional AI features are bring-your-own-key (see SUB-3): the AI provider is a vendor the customer configures and contracts with directly, not a Paridity sub-processor. (Data-Flow Disclosure §4.) |
Verified |
| SUB-3 | What data does the optional AI capability expose, and how is it controlled? | Only if the customer enables the AI features (AI Triage / AI Insights), prompt context for the requested explanation is sent to the model provider the customer configures with their own key (e.g. their own Anthropic account) - with object/schema/column names masked (mask_object_names - on this prompt path the masking is absolute; see SUB-5 for the different guarantee on the MCP agent surface), prompt context scrubbed, and a data-residency provider restriction applied; raw evidence values are not sent. Controls: off by default at the feature level, the provider key lives in the customer's own secrets backend, per-tenant settings and quota, and deterministic fallback when AI is unavailable. There is no Paridity-provided default provider, so the AI path adds no Paridity sub-processor. AI never determines correctness. |
Verified |
| SUB-4 | How will we be notified of sub-processor changes? | The sub-processor disclosure (Data-Flow Disclosure §4) is a maintained Trust Center document that names EGMW's current sub-processors (SUB-2) and is updated when one is added; if the hosted deployment option ships, it will be updated with the exact control-plane data classes (opaque IDs, counts, status, timings only) and any new sub-processors before customers contract against it. | See response |
| SUB-5 | If we let our own AI agents query Paridity over MCP, what is exposed and who is the disclosing party? | The /mcp agent surface is an authenticated customer API at parity with REST, not a Paridity-routed LLM path: the customer's own MCP client authenticates with the customer's own credentials and forwards what it reads to a model the customer chose and contracts with directly. Paridity is not a sub-processor for that hop. Exposure equals REST exposure - object/schema/column names and run metadata, plus evidence aggregates and masked samples under the same query-time evidence masking (store_raw_diff_values, mask_in_ui) and the same per-tool permissions. State plainly: mask_object_names is best-effort here, not absolute - a defined list of object-name fields is tokenized and a field carrying a name that is not on that list is returned in clear text. That is a deliberate design decision (deny-by-default masking would leave an agent unable to say which column drifted). In short: your agent, your credentials, your disclosure. A single tenant toggle deliberately governs both surfaces - a separate MCP masking control was considered and rejected (decision record 6, same document), because it would present a best-effort mechanism as a guarantee a reviewer could rely on; no independent MCP masking control exists. Residual risk we state rather than leave to be found: same authorization is not the same disclosure surface - a person reading a table name on a screen does not thereby place it in an LLM context window, vendor logs, or a retention window; an MCP client does, automatically, on every call. Controls that bound it: off by default, and in production the API refuses to start with AI enabled unless a tenant has explicitly opted in (a required second opt-in); per-tool RBAC using the same permission strings as REST; tenant scope taken from the authenticated principal and never from a tool argument; a read-only catalog with arbitrary SQL, shell, secret retrieval, file access, and direct database modification permanently excluded; every dispatched tool call audited (success or failure alike); and a per-principal, per-tool rate limit that sheds abuse before dispatch. Classified data-plane and runs entirely inside the customer's own environment, like the rest of the platform. The control only you can apply: govern which MCP clients and models may hold Paridity credentials, as you would REST API keys. |
Verified |
6. Business continuity & disaster recovery¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| BCD-1 | What are your RPO/RTO commitments? | Documented targets per deployment tier for the Paridity control plane (Postgres + Temporal), configured in the customer's own account: Small (single-AZ) RPO 1 h / RTO 4 h; Medium (multi-AZ, 1 replica) RPO 5 min / RTO 1 h; Large (multi-AZ, 2 replicas, WAL archive) RPO 5 min / RTO 30 min; Global (per-region failover) RPO 1 min / RTO 15 min. Source/target system availability is the customer's responsibility. | Supported |
| BCD-2 | Are backups automated? | Yes for Helm/Terraform deployments: managed Postgres (RDS / Azure Flexible Server / Cloud SQL) is provisioned with 14-day backup retention + point-in-time recovery (PITR), multi-AZ/HA on medium/large tiers. Temporal's own persistence database is covered by the same managed backups. The runbook instructs verifying via terraform output rather than assuming. |
Supported |
| BCD-3 | Are restores tested? | Yes - a full restore drill has been executed against Paridity's reference environment (a real backup restored and validated end-to-end, 2026-08-17), and restore validation is scheduled as an automated quarterly CI drill (first scheduled run 2026-11-01): a real backup is restored to a scratch database and five checks run (schema integrity, evidence row counts against the backup artifact, critical-table counts, evidence anchors, and the audit hash chain), preceded on every drill by mandatory prove-can-fail probes so a passing drill is known to be able to fail. A drill against your own production backup is your operational task, using the shipped script. | Verified |
| BCD-4 | What is lost if a worker or orchestrator fails mid-run? | No evidence or audit data: Temporal persists workflow history durably and resumes in-progress workflows after recovery; a failed diff activity retries from scratch (in-flight DuckDB state is ephemeral by design - a documented limitation for very long diffs; checkpointing is on the roadmap with no committed release). Evidence and compare_started_at are immutable and restore as-is. |
Supported |
| BCD-5 | Does your (the vendor's) availability affect our operations? | Only in a bounded way. The entire stack, including orchestration, runs in the customer's environment. The one Paridity dependency is the licence service: in releases that enforce the licence (every release after v1.4.0) the installation runs normally for 7 days without it, then a paid licence runs proof-only (counts and hash totals, no field-level diffs, no new configuration brought into service) until it is reachable again. Runs are never stopped. Multi-region failover is not yet built (single-region per deployment; V2.0 roadmap item). | Verified (structural; bounded licence dependency) |
7. Supply chain / SBOM¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| SCM-1 | What is your open-source license posture? | Every dependency is MIT, Apache 2.0, or comparably permissive (e.g. PostgreSQL License) - no GPL, AGPL, or SSPL component anywhere in the platform, backed by a full per-dependency license inventory and enforced by blocking CI license gates across all three ecosystems (Python, npm production tree, Rust) - each gate proven able to fail. Two components are deliberately excluded rather than carved around: HashiCorp Vault (BSL 1.1) is optional-only, never default/required; Confluent Platform components are excluded in favor of Apache Kafka core only. | Verified |
| SCM-2 | Can you provide an SBOM? | Yes - every release publishes a machine-generated SPDX-JSON SBOM per container image (backend/workers, UI, docs), generated by syft from the published image digests (never a local rebuild) and shipped both as GitHub Release assets (sbom-paridity-{api,ui,docs}-vX.Y.Z.spdx.json) and as cosign in-toto attestations verifiable against the release's signing identity (live since v1.1.1; most recently v1.4.0, 2026-10-28; releases up to v1.3.1 carry the product's former name, dataalign, in their file and image names). The fully pinned, committed dependency lockfiles remain the source-level manifests of record. |
Verified |
| SCM-3 | Are dependencies scanned for known vulnerabilities? | Yes - CI audits pinned Python dependencies (pip-audit on requirements-ci.lock) and production npm dependencies (npm audit --omit=dev) as blocking gates, alongside a blocking Semgrep static-analysis gate. Production images are Trivy-scanned for fixable HIGH/CRITICAL vulnerabilities before every release and the latest release's images are re-scanned weekly. An advisory is accepted only explicitly, one advisory id at a time, each with a written rationale and a stated removal condition (the more recent ones also with a reachability note); there is no blanket suppression. |
Supported |
| SCM-4 | How do customers receive and verify your software? | Deployment is from the Paridity Helm chart and container images plus Terraform reference modules, applied by the customer in their own account. Every released image and the Helm chart are cosign keyless-signed (Sigstore - the signing identity is the release workflow, recorded in the public Rekor transparency log) and carry an SPDX-JSON SBOM attestation. Customers verify signature and digest before mirroring into their own registry (cosign verify --certificate-identity … --certificate-oidc-issuer https://token.actions.githubusercontent.com; live since v1.1.1), on top of their own registry-scanning and image-policy controls. A formal SLSA provenance predicate is not yet generated (roadmap). |
Verified |
8. Incident response & vulnerability management¶
| # | Question | Paridity response | Status |
|---|---|---|---|
| IRV-1 | Have you had an independent penetration test? Share the report. | No. No third-party penetration test has been performed and none is scheduled. What is done is automated, on every code change in CI: Semgrep static analysis (Python, security-audit, and OWASP Top Ten rule sets), dependency vulnerability audits (pip-audit, npm audit on production dependencies), a full-history Gitleaks secret scan, and a Trivy configuration scan; release images are Trivy-scanned for fixable HIGH/CRITICAL vulnerabilities before release and the latest release is re-scanned weekly (AIS-4). A dynamic scan (DAST) runs weekly in CI: OWASP ZAP against a throwaway stack built from the current code - a passive baseline scan of the production UI image, and an authenticated, active scan of the API driven by the API's own OpenAPI document. The job fails on any finding in a FAIL-level class (injection, cross-site scripting, path traversal, XML external entities, remote code execution, server-file disclosure, open redirect, and the security headers already in place) and when the API scan cannot be shown to have run authenticated. This is automated scanning, not a penetration test: it does not chain findings, test business logic or tenant isolation, or test a real deployment's ingress, TLS or identity provider. Because Paridity runs in the customer's environment, the customer may test its own deployment with its own tools or testers (Acceptable Use Policy §6.1); testing EGMW-operated systems such as the licence service needs EGMW's prior written authorization (§6.2). Context: there is no Paridity-hosted service holding customer data (the one EGMW-operated service, the licence service, receives licence data only). An internal, AI-assisted review with test-pinned findings is described at IRV-1a; it is not a third-party assessment. |
See response (not performed, none scheduled) |
| IRV-1a | Beyond automated scanning, has the product's code been reviewed for security? | Yes, internally. An internal, AI-assisted code review of the Paridity source (#3357), carried out by EGMW with an AI model in four passes from 2026-10-30 to 2026-11-01. No outside party took part. Scope: tenant isolation and authorization; authentication (bearer tokens, SAML, OIDC, SCIM, API keys); generated SQL; licensing; secrets and logging. Every item in scope was read line by line and either demonstrated as a finding, ruled out with a recorded counter-check, or pinned by a test. A finding required a test, committed to the repository, that failed against the code before the fix. Five findings: three high (#3365, #3369, #3398), one medium (#3383), one low (#3384); all five were fixed by 2026-11-01. This is a secure-development control, not a penetration test and not a third-party assessment: it reviewed source code and a development stack, did not test a customer deployment's ingress, TLS or identity provider, and did not exercise exploit chains against live credentials. The review record (method, coverage, findings, hypotheses not demonstrated, ruled-out items with their counter-checks, follow-ups) is retained by EGMW and available on request. | Verified |
| IRV-2 | Describe your incident-response plan and breach-notification commitments. | No formal plan. EGMW is a small business and has no formal, documented incident-response plan today. Structurally: a Paridity-side incident cannot expose customer data (none is held), and a Paridity-side outage cannot stop customer reconciliation runs (the one runtime dependency, the licence service, degrades a paid licence to proof-only after 7 days, never a halt - see BCD-5; a licence-service compromise is covered in AIS-6); incidents inside the customer's deployment fall under the customer's own IR process, which Paridity's audit trail is built to support (hash-chained audit log, append-only evidence, network attribution via actor_ip). Contractual breach-notification terms are addressed in the agreement. |
See response (no formal plan) |
| IRV-3 | How would we detect and investigate misuse within the platform? | Every admin action and terminal run status is written to cfg.audit_log through a single enrichment chokepoint, with actor, entity, action, timestamp, and source IP; the log is hash-chained (altering, deleting, or reordering any row breaks every subsequent entry_hash), with signed sealing checkpoints that can additionally be anchored outside the platform entirely - to WORM object storage (S3 Object Lock / Azure Blob immutability / GCS retention lock), an RFC 3161 timestamp authority, and your SIEM (each anchor live-verified). Evidence bundles and the audit chain are independently verifiable - the audit chain via GET /audit/verify, and bundles offline via the shipped fail-closed verification tool with the customer-held signing key. |
Verified |
| IRV-4 | How do you become aware of vulnerabilities in your product and dependencies? | Blocking CI gates: dependency audit (Python pip-audit, npm production audit), Semgrep static analysis, and a full-history Gitleaks secret scan run on every code change; production images are Trivy-scanned before release and the latest release is re-scanned weekly against the current CVE feed; migrations gate against a fresh database; Dependabot raises weekly update PRs across pip/npm/cargo/GitHub-Actions/Docker. A coordinated vulnerability-disclosure policy ships as SECURITY.md (private reporting via GitHub Security Advisories plus the account-contact channel); a dedicated monitored security@ mailbox and any bug-bounty program are pre-GA. |
Supported |
| IRV-5 | How are security fixes delivered to customers? | As versioned releases (chart + images) the customer applies via helm upgrade on their own schedule. Database migrations are forward-only and CI-verified to apply cleanly to a fresh database; the DR runbook documents PITR-based rollback for migration-caused incidents (a helm rollback reverts images/config only, never applied migrations). |
Supported |
Appendix - canonical sources¶
Answers in this document distill (never extend) the following canonical documents. For contract-grade reliance, verify against them:
- Security Whitepaper - architecture, access control, secrets, data protection, OSS posture, roadmap-honesty table.
- Data-Flow & Sub-Processor Disclosure - data classes, data-flow diagram, sub-processor list.
- Audit & compliance proof - audit trail, evidence immutability, hash chains, signing, offline verification.
- Paridity glossary - canonical terminology (
hash_total,row_hash,field_diff,config_checksum, RBAC roles). - Additional materials - disaster-recovery targets and procedures, the pre-production security checklist, and the full dependency/license inventory - are available to reviewers on request through your Paridity account contact.
Follow-up questions or a completed copy of your firm's own questionnaire template:
route through your Paridity account contact or the Trust Center index
(security/TRUST_CENTER.md, in progress).
Classification: Customer Confidential - © 2026 Evil Genius MindWorks LLC. All rights reserved. Do not distribute outside the intended recipient without Paridity approval.