Security

1. Our approach

Capallo's core product is a governance platform. Separation of duties, evidence chains, and audit trails are not bolt-on features layered on top of an existing application. They are the foundation the product is built on. The same controls Capallo puts on a group's payments are reflected in how we build, ship and operate the service.

This page describes the security controls we have in place today and the ones we are working toward. Where a control is not yet in place, we say so. We will not list certifications we do not hold.

2. Application security

2.1 Authentication

Authentication is handled by our authentication provider, which supports multi-factor authentication and single sign-on. Capallo does not store user passwords directly. Session tokens are issued, scoped, and revoked through our authentication provider's standard mechanisms.

2.2 Role-based access control

Every authenticated request is authorised against a role-based permission catalogue. Permissions are enforced at the API layer, not only in the user interface, so the application cannot be bypassed by directly calling the API. Roles are scoped to specific entities or workspaces and follow the principle of least privilege.

2.3 Separation of duties

Capallo enforces separation-of-duties constraints natively, including:

• a submitter cannot approve their own decision (subject to a workspace exception mode for single-treasurer setups);
• an executor cannot attest their own execution;
• an executor cannot reconcile the same decision.

These constraints are enforced server-side and cannot be circumvented from the user interface.

2.4 Append-only audit log

Significant actions across the platform generate audit events, stored in order in a chain where each event carries a hash of the one before it, so changing a past event breaks the chain from that point. The application never edits or deletes audit events, and an automated test blocks any code that tries. The audit log is one of the core trust artefacts of the platform and is available to customers through the application and export tooling.

2.5 Input validation and output encoding

Input validation is enforced at the API boundary using strongly typed request schemas. Output is encoded appropriately to prevent injection and cross-site scripting. The application uses parameterised database queries through an ORM.

2.6 Workspace isolation

Every customer workspace is isolated at the data layer. All API operations scope queries to the requesting actor's workspace, so data from one customer's workspace cannot be returned to another customer's users.

3. Data protection

3.1 Encryption in transit

All traffic between users and the Capallo Service is encrypted using TLS 1.2 or higher. HTTPS is enforced; plain HTTP is redirected. Modern cipher suites are configured.

3.2 Encryption at rest

The database sits on a Render disk, which Render encrypts at rest. Evidence files are stored in Cloudflare R2, which encrypts every object and its metadata at rest (AES-256). Encryption keys are managed by those providers.

3.3 Data residency

Capallo currently runs on Render in Frankfurt, Germany. Evidence files are stored in Cloudflare R2 through its EU jurisdiction, which keeps them in the EU. Customers with specific data residency requirements should contact us at security@capallo.io to discuss their requirements.

3.4 Backups

Render takes an automatic snapshot of the database disk every 24 hours. Snapshots are encrypted and kept for at least seven days.

3.5 Data minimisation

Capallo's data model captures only the information required to deliver the governance workflows it supports. We do not collect sensitive financial credentials, payment card details, or biometric identifiers as part of the standard product flow.

4. Infrastructure

4.1 Cloud provider

The application runs on Render and evidence files are stored in Cloudflare R2. We rely on those providers for the physical, environmental and infrastructure controls of the systems Capallo runs on.

4.2 Network controls

Network access to production resources is restricted at the cloud provider level. Production databases are not accessible from the public internet. Administrative access to production systems requires authentication through a managed identity provider with multi-factor authentication.

4.3 Secrets management

Secrets, including API keys and encryption keys, are stored in a managed secrets vault and are not committed to source control. Secret access is scoped to the services that require them and is logged.

5. Engineering and operations

5.1 Software development lifecycle

Code changes are managed through version control and automated tests, and every deployment is recorded by the hosting provider.

5.2 Dependency management

Open-source dependencies are tracked. We monitor for known vulnerabilities in our dependencies and apply security updates promptly, prioritised by severity.

5.3 Logging and monitoring

Application and infrastructure logs are collected and retained. Anomaly and error monitoring is in place. Security-relevant events are reviewed on a recurring basis.

5.4 Incident response

We maintain an internal incident response process. If a security incident affects Customer data, we will notify affected customers promptly in accordance with applicable law and our contractual obligations.

5.5 Access to production systems

Access to production infrastructure and customer data is limited to Capallo personnel with a legitimate operational need. Access is reviewed periodically. Administrative actions are logged.

6. Compliance roadmap

Capallo is an early-stage company and we are transparent about where we sit on the compliance journey today.

6.1 In progress

• SOC 2 Type I: target completion Q1 2027. Evaluating compliance automation platforms to manage evidence collection and control monitoring.
• Independent penetration test: scheduled prior to first paying customer onboarding.
• Cybersecurity insurance: under evaluation.

6.2 On the roadmap

• SOC 2 Type II: typically twelve (12) months after Type I, requiring a continuous operating evidence window.
• ISO 27001: under evaluation; timeline depends on customer demand.
• Coordinated vulnerability disclosure program: once we have customer scale to support it responsibly.

6.3 Not on the roadmap

Capallo is software, not a financial product or service. We do not process payments or hold customer funds, so PCI DSS does not apply to the Service. We are not regulated as an Authorised Deposit-taking Institution (ADI) by APRA. Capallo does not hold an Australian Financial Services Licence (AFSL) and does not provide financial product advice.

7. Customer responsibilities

Security is a shared responsibility. Customers can do their part by:

• enforcing multi-factor authentication for all Authorised Users;
• provisioning users with the least privilege required for their role;
• reviewing role assignments regularly and revoking access for departing personnel;
• enabling and not disabling the Service's built-in separation of duties constraints, except where the workspace exception mode is deliberately used for genuinely small teams;
• training Authorised Users to recognise phishing and social engineering;
• notifying us promptly at security@capallo.io of any suspected security incident affecting their workspace.

8. Reporting a vulnerability

If you believe you have discovered a security vulnerability in Capallo, we appreciate responsible disclosure. Please email us at security@capallo.io with as much detail as possible, including:

• a description of the issue;
• steps to reproduce;
• any proof-of-concept code or screenshots; and
• your name and contact details if you would like attribution.

We will acknowledge receipt promptly and work with you to understand, validate, and remediate the issue. We ask that you do not publicly disclose the issue until we have had a reasonable opportunity to address it.

9. Contact

Security questions, due diligence requests, or vulnerability reports: security@capallo.io.

Customer security questionnaire responses can typically be turned around within five (5) business days. Please send the questionnaire with as much context as possible about your organisation and timeline.