Most software companies talk about security after they’ve had an incident. We prefer to talk about it now, while we’re still building.
Claraxiom is in active development. We don’t have production customers yet. But we do have a clear position on what it means to handle business data responsibly — and we want it to be public from day one.
The core principle
Your company’s data is not ours. It’s yours.
When a business entrusts its accounting, inventory, or contracts to an external system, it’s handing over something valuable. Our job is to safeguard that information as if it were our own, return control to the customer whenever possible, and be completely transparent about how we do it at all times.
We don’t believe in security as a marketing feature. We believe in it as an operational obligation.
Infrastructure and data at rest
Before any Claraxiom product processes real customer data, the infrastructure will meet the following standards:
Encryption in transit. All traffic between client and server via TLS 1.3. No HTTP. No exceptions for any endpoint, including internal APIs.
Encryption at rest. Databases, backups, and stored files encrypted with AES-256. Encryption keys managed separately from the data they protect.
Verified backups. Making backups isn’t enough — you have to prove they work. Automated periodic restore tests to verify integrity before it’s ever needed.
Environment separation. Production data never in development or staging environments. Test data is synthetic, not masked copies of real data.
Access control
Least privilege by default. Every team member accesses only what they need for their specific role. Permissions are granted explicitly, not inherited by default.
Mandatory 2FA. Two-factor authentication required for all internal access to production systems, without exceptions based on role or seniority.
Auditable access logs. All access to customer data is recorded — who, when, from where, what operation. Immutable logs with a minimum 12-month retention.
Immediate offboarding. When someone leaves the team, access is revoked the same day. No orphaned accounts, no shared credentials that outlive the people who used them.
Secure development lifecycle
Security isn’t evaluated only in production — it’s built into every stage of development.
Security-focused code review. Every change touching authentication, data handling, or permission logic goes through specific security review before merge, not just functional review.
Monitored dependencies. Automated vulnerability scanning on third-party dependencies. Active update policy, not reactive.
External penetration testing. Before each product launch, a security audit by an independent external firm. Findings are actionable — they don’t go into a drawer.
Bug bounty. Once in production, a formal rewards program for researchers who responsibly disclose vulnerabilities.
Responsible disclosure
If you discover a vulnerability in any Claraxiom product or infrastructure, we want to know.
Our commitment:
- Acknowledgment response within 72 hours
- Assessment and remediation plan within 7 business days
- Critical vulnerability fixes within 30 days
- Public recognition for the reporter, if desired
- Zero legal action against researchers acting in good faith
Reports to [email protected]. Please include reproduction steps, estimated impact, and any mitigation suggestions you may have.
Regulatory compliance
Companies operating in Costa Rica handle data under the framework of Law 8968 on the Protection of Individuals Regarding the Processing of Personal Data. All Claraxiom products are designed to comply with this law at the architecture level, not as a post-hoc patch.
For customers operating under SUGEF regulation or requiring compliance with international standards (SOC 2, ISO 27001), we have that path on our roadmap. If your organization has specific compliance requirements, let’s talk before you sign — not after.
The path to certification
We’re being honest: we don’t have SOC 2 yet. We don’t have ISO 27001. We’re in development.
What we do have is architecture designed to support those certifications, and the commitment to obtain them as we scale. When we do, they’ll be verifiable by independent third parties — not just statements on a webpage.
Why we say this before we have it
Because commitments made in public are harder to abandon.
And because businesses that trust their operations to external software deserve to know what standard their vendor operates at before signing — not after something goes wrong.
If you have questions about security, want to review our architecture before contracting, or simply want to better understand how we’ll protect your data, write to us at [email protected]. We respond.
Interested in this topic?
Let's talk