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 our customers use to govern their treasury decisions 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 Immutable audit log

Significant actions across the platform generate audit events. Audit events are stored in an append-only chain. Tampering with prior events would invalidate the chain's integrity. 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

Customer data stored in our primary databases and object storage is encrypted at rest using the encryption mechanisms provided by our cloud infrastructure. Encryption keys are managed by the cloud provider's managed key service.

3.3 Data residency

Our primary production environment is hosted in AWS Sydney (ap-southeast-2). Customer workspace data is stored in this region by default. Customers with specific data residency requirements should contact us at security@capallo.io to discuss their requirements.

3.4 Backups

Production databases are backed up regularly. Backups are encrypted and retained according to our internal backup policy. Restore procedures are documented and tested.

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

Capallo runs on Amazon Web Services (AWS), inheriting the physical, environmental, and infrastructure controls of that provider. AWS maintains a wide range of independent certifications, including SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, and ISO 27018.

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, peer review, and automated testing. Production deployments are gated by code review, successful test runs, and an audit trail of the deployment itself.

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. A compliance automation platform is being procured to manage evidence collection and control monitoring.
• Independent penetration test — scheduled prior to first paying customer onboarding.
• Cybersecurity insurance — being procured.

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.