Skip to content

Information Security Policy

Statement

This page is ClaimGuard's umbrella Information Security Policy: a single statement of the company's posture on protecting customer data, user identities, and the systems that hold them, plus a map of the underlying control pages where each commitment is concretely implemented.

The intent is to give a reader (auditor, prospect, internal engineer) one entry-point that answers: "what does ClaimGuard claim about its security overall, and where can I verify each claim?"

Statement of intent

ClaimGuard commits to:

  • Protect customer data with encryption at rest and (where available) in transit, role-and-org access control, audit logging, and tenant isolation at the application layer.
  • Operate cloud infrastructure under least-privilege identity, immutable audit logging of every privileged action, and a documented hardening trajectory.
  • Develop the application under a documented secure-development lifecycle with branch-protected main, required review, a versioned deferral policy for accepted risk (.snyk), and a step-by-step change journal for cloud-posture changes.
  • Disclose third-party processors of customer data in a maintained list, and treat each addition as a security-review item.
  • Respond to security findings through a published vulnerability disclosure policy with acknowledgement and remediation SLAs.
  • Use AI responsibly — humans, not models, make claim determinations; AI use is documented; data sent to AI vendors is minimized.
  • Keep the trust portal honest — every claim on this portal links to the evidence; every gap is named.

Scope

This policy covers:

  • The ClaimGuard production application, the production VM claim-guard-app-1 in GCP project train-cvit2, and the data and secrets that VM holds.
  • The trust portal at trust.dtectvision.ai itself.
  • All third-party services (subprocessors, scanning tools, source hosting) used in operating ClaimGuard.

It does not cover:

  • Sibling research workloads that share the GCP project (those VMs are out of scope for ClaimGuard's controls — see Cloud provider for the multi-tenancy disclosure).
  • Customer-side systems integrating with ClaimGuard.
  • Personal devices or networks of operators outside their use of Workspace credentials.

How this policy is implemented

Each commitment in the "Statement of intent" above maps to one or more concrete control pages on this portal. The map:

Commitment area Primary pages
Encryption (at rest, in transit, secrets) Cryptography, Encryption at rest, Encryption in transit, Secrets management
Identity and access Authentication, Authorization, Identity provider, MFA, Access management, Privileged access
Audit logging Audit logging (cloud), Application audit logging
Application security Secure SDLC, SAST, SCA, Dependency management, Snyk remediation summary
Change & risk Change management, Risk management, Incident response
Infrastructure & resilience Cloud provider, Network architecture, Network security, Hardening, Backups, Business continuity
Vendor and data Vendor management, Subprocessors, Data classification, Data retention, Data residency
AI AI transparency, AI risk management, Prompt guardrails
Disclosure & report Vulnerability disclosure, Pentest summary
Compliance SOC 2, ISO 27001, GDPR, CCPA

Roles and responsibilities

  • Founder pair (roee@dtectvision.ai, dor@dtectvision.ai): policy ownership, incident-response primary, periodic-review sign-off, vendor approvals, AI-use approvals.
  • Engineers: adherence to the documented invariants (docs/security/README.md), the engineering protocol (docs/security/PROTOCOL.md), and the change-management process. Reporting suspected security issues internally.
  • External researchers: governed by the Vulnerability Disclosure Policy.
  • Customers: act as data controllers / businesses for the personal data they upload; ClaimGuard supports them in fulfilling data-subject and consumer rights.

Governance

  • Trust portal as living evidence. This portal is the canonical external-facing summary. Every page is dated; every partial page names its gaps and the work that closes them.
  • Hardening journal as canonical change record. docs/security/HARDENING-LOG.md is the time-ordered, command-level record of cloud-posture and trust-portal changes.
  • Annual deferral renewal of the .snyk policy file (next: 2027-04-22). See SCA.
  • Quarterly access review — scheduled before SOC 2 fieldwork; cross-listed on Access management.
  • Annual policy review — this page itself is reviewed at least once per year by the founder pair, who attest that the control-page set still reflects reality.

Status

partial — verified 2026-04-29.

What's in place:

  • A single-page map of every commitment to its evidence.
  • A documented role / responsibility set.
  • Two canonical records — this trust portal and the HARDENING-LOG.md journal — that together cover the design and operation of every control.

Known gaps

  • No dedicated security officer. The founder pair holds the function. Appropriate at current scale.
  • No internal-audit cycle distinct from the planned SOC 2 readiness assessment.
  • No documented training programme for new engineers (today the engineering invariants in docs/security/README.md are the closest artifact).
  • No formal exception-management workflow — exceptions to this policy today are negotiated by founder review at PR time.

Roadmap

  • First annual policy-review attestation — record dated and signed by both founders, stored alongside the trust portal.
  • Engineer-onboarding security checklist that walks a new engineer through docs/security/README.md, the engineering protocol, and a sample PR review.
  • Internal-audit cycle before SOC 2 fieldwork.
  • Documented exception-management workflow if compliance scope grows beyond what PR-time judgment can sustain.