Security Statement

1. Data Encryption

ChainShield protects your data with industry-standard encryption at every layer:

• At rest: All data stored in our PostgreSQL database is encrypted using AES-256 encryption via Supabase's managed infrastructure
• In transit: All communications between your browser and our servers are secured with TLS 1.2+, ensuring data cannot be intercepted or tampered with
• API keys: Third-party API keys stored within the platform are encrypted with application-level AES-256 encryption before being written to the database — they are never stored in plain text

2. Secure by Design

Multi-tenancy isolation is fundamental to ChainShield's architecture, not an afterthought:

• Row-Level Security (RLS): Every database table enforces row-level security policies, ensuring tenants can only access their own data — even if application logic were bypassed
• Data isolation model: ChainShield discovers and stores information about vendors from public sources (domains, certificates, CVEs, published vulnerabilities, ABR records, news coverage). Because this information comes from the public internet and is identical regardless of who is looking at the vendor, a single vendor record can be referenced by many customer organisations. ChainShield does not segregate public vendor facts by tenant. Your organisation's data remains strictly private. This includes how you use each vendor, your criticality and data-sensitivity ratings, your regulatory scope, your accepted-risk decisions, your assessment responses, your internal notes, and your per-organisation risk score. This information is stored separately from public vendor intelligence (primarily in the organisation_vendors junction table) and is protected by Postgres Row-Level Security so it is only visible to your organisation's users, your assigned MSP (if any), and ChainShield staff acting under documented support procedures.
• Service role restrictions: Elevated database privileges (service role) are used only within authenticated server-side actions — never exposed to client-side code
• Input validation: All API endpoints enforce strict input validation, rate limiting, and authentication checks before processing requests

2a. What We Share and What We Isolate

ChainShield operates a two-layer data model that separates shared public vendor intelligence from tenant-private organisation context:

Shared Public Vendor Intelligence

ChainShield discovers and stores information about vendors from public sources (domains, certificates, CVEs, published vulnerabilities, ABR records, news coverage). Because this information comes from the public internet and is identical regardless of who is looking at the vendor, a single vendor record can be referenced by many customer organisations. ChainShield does not segregate public vendor facts by tenant. Examples include:

• Vendor name and domain
• Discovered assets (subdomains, IP addresses)
• CVEs and published vulnerabilities
• ABR registration details
• News coverage and public reports

Tenant-Private Organisation Context

Your organisation's data remains strictly private. This includes how you use each vendor, your criticality and data-sensitivity ratings, your regulatory scope, your accepted-risk decisions, your assessment responses, your internal notes, and your per-organisation risk score. This information is stored separately from public vendor intelligence (primarily in the organisation_vendors junction table) and is protected by Postgres Row-Level Security so it is only visible to your organisation's users, your assigned MSP (if any), and ChainShield staff acting under documented support procedures. Examples include:

• Criticality and data-sensitivity ratings per vendor per organisation
• Regulatory scope (e.g., CPS 230, SOCI, Privacy Act applicability)
• Accepted-risk decisions and exception records
• Assessment questionnaire responses
• Internal notes and remediation plans
• Per-organisation risk scores

3. Human-in-the-Loop AI

ChainShield uses AI to accelerate risk analysis, but findings pass layered review — automated and human — before your organisation acts on them:

• Two-tier review gate: Every AI-generated finding first passes deterministic validation checks, then review by an independent AI reviewer that runs on a separate model from the agents that generated the finding — a deliberate cross-model check, not the same model marking its own work
• Analyst approval: Critical and high-severity findings are never auto-approved. A ChainShield analyst reviews and approves findings before they become visible to organisation users — enforced at the database layer, not just in the interface
• Automatic gating: Findings rated CRITICAL, or those that trigger Notifiable Data Breach (NDB) obligations, are automatically held for human review before action
• Schema validation: All LLM responses are validated against expected schemas before being stored — malformed or unexpected AI outputs are rejected, not silently accepted
• No autonomous actions: The AI system analyses and recommends — it does not take autonomous remediation actions without explicit human approval
• Transparent provenance: Every AI-generated finding and risk narrative is clearly labelled as AI-generated, so analysts can distinguish machine outputs from manual assessments
• Your team decides: Organisation users can review, edit, accept, or reject any AI-generated content — you maintain full control over what your organisation sees and acts on

3a. What the AI Can and Cannot See

ChainShield's AI agents analyse open-source intelligence and vendor-scoped data. Questionnaire answers, vendor correspondence, stored contact records, account data, and your organisation's context never enter the AI layer. ChainShield analyst review notes steer the agents — never attributed to your organisation.

Processed by the AI layer

• Publicly sourced vendor data (domains, CVEs, ABR records, discovered infrastructure)
• Findings derived from public sources

Never processed by the AI layer

• Account data (user names, email addresses)
• Credentials and API keys
• Assessment questionnaire responses containing personal information
• Personally identifiable information (PII)
• MFA secrets or authentication data

See the Privacy Policy (section 4, AI Processing) for the full statement of how AI processing works.

4. Access Controls

ChainShield enforces granular access controls across the platform:

• Role-based access control (RBAC): Four permission tiers — admin, manager, user, and viewer — each with precisely scoped capabilities
• Multi-factor authentication (MFA): Supported for all accounts, with enforced MFA available for sensitive administrative routes
• API key scopes: API keys are scoped to specific operations and organisations, following the principle of least privilege
• Session-based authentication: Secure session management via JWTs with appropriate expiry, refresh, and revocation controls

5. Audit Logging

Comprehensive audit trails ensure accountability and support incident investigation:

• State change logging: All significant state changes — user actions, scan executions, configuration updates — are logged with timestamps and actor identification
• Structured logging: Logs use structured formats with correlation IDs, enabling efficient tracing across distributed operations
• Exportable audit trails: Audit logs can be exported for compliance reporting, regulatory submissions, and third-party review
• Retention: Audit logs are retained for 24 months, consistent with operational and regulatory requirements under the Privacy Act 1988 (Cth)

6. Australian Compliance

ChainShield is purpose-built for the Australian regulatory landscape. Our risk framework maps directly to the following standards and legislation:

• ISM (Information Security Manual): ASD's baseline security controls for Australian Government entities
• CPS 234 (Information Security): APRA's prudential standard for regulated financial institutions
• CPS 230 (Operational Risk Management): APRA's standard for operational resilience and third-party risk
• Privacy Act 1988 (Cth): Compliance with Australian Privacy Principles (APPs) for personal information handling
• Notifiable Data Breaches (NDB): Automated detection of findings that may trigger mandatory breach notification obligations
• SOCI Act (Security of Critical Infrastructure): Controls aligned to critical infrastructure protection requirements
• Cyber Security Act 2024: Compliance with Australia's latest cyber security legislation

7. SOC 2 Alignment

ChainShield implements controls in alignment with SOC 2 Type II trust services criteria across all five categories. ChainShield is not currently SOC 2 Type II certified.

• Security: Protection against unauthorised access through RLS, RBAC, encryption, and MFA
• Availability: Platform uptime monitoring, circuit breakers for external dependencies, and graceful degradation
• Processing integrity: Schema validation of AI outputs, deterministic risk scoring, and finding deduplication
• Confidentiality: Tenant isolation, encrypted API key storage, and scoped access controls
• Privacy: Compliant data handling, retention policies, and data subject request support

8. Subprocessors

ChainShield uses the following third-party service providers to operate the platform. All processors operate under data processing agreements compliant with the Privacy Act 1988 (Cth) and Australian Privacy Principles (APPs).

9. Responsible Disclosure

We value the security research community and welcome responsible disclosure of vulnerabilities. If you believe you have found a security issue in ChainShield, please contact us:

Email: security@chainshield.com.au

We ask that you provide sufficient detail to reproduce the issue and allow us reasonable time to remediate before public disclosure. We will acknowledge receipt within 48 hours and aim to provide a substantive response within 5 business days.