Security

We build security before we build anything else.

Not a layer added once the system works.The first thing that exists.

Most of the risk is designed out before anything goes live.

The misread

Most systems are secured after they already work.

By the time security is added, the weaknesses are already holding things up. They have become load-bearing. Removing them means rebuilding the parts everyone now depends on, so no one does, and the system ships with the cracks inside it.

We start at the other end. The threat model comes before the build, so the weak points are designed out while they are still cheap to remove, instead of discovered later when they are not.

AUCTUS Cyber

We attack our own systems before anyone else can.

Before a system ships, it is run against our own adversarial program until it holds. The point is not to prove it is safe. The point is to find where it is not, on purpose, repeatedly, while there is still time to fix it.

After it ships, that program keeps running. It does not wait for an annual review. It keeps testing, keeps watching, and keeps learning from what it finds, because the threats do not pause between audits either.

We built this to point at one thing only: our own work. It is never aimed at anyone else's systems, including at a client's request. The discipline is the product. The restraint is part of it.

Auditability

Nothing the system does is invisible to the people who own it.

Every action the system takes is recorded, attributable, and recoverable. Who, what, when, and why. Not only for security. An operation should never contain steps that no one can see or explain after the fact.

When something matters, the answer to what happened is not a reconstruction. It is a record.

What we refuse

Some things we will not do, by design.

We do not accept payment card numbers through AUCTUS Voice, in any configuration, including inside the wider system. Some data should never pass through a channel like that, so it does not.

We do not point our offensive tooling at anyone but ourselves. If a client asks us to test or break into a system that is not theirs to authorize, the answer is no.

We hold the minimum data required to run the system, and no more. The safest data is the data we never took.

A firm that claims to cover everything has usually not thought about it hard enough.

For technical review

The operating controls are written down because they have to be.

Control Surface

Identity and auth

Passkeys, MFA, SSO through SAML or OIDC, and device checks for administrative actions.

Secrets and keys

KMS-backed encryption, key rotation, per-environment isolation, and no secrets in code.

Data security

AES-256 at rest, TLS in transit, row-level isolation, and field-level controls for sensitive data.

Approval gates

Co-approval for mass send, data export, permission changes, and other sensitive operations.

Evidence and logs

Action logs capture actor, scope, result, and timing, with retention configurable by the operation.

Network posture

IP allowlists, private networking or VPC peering options, and egress controls where the deployment requires them.

Data Lifecycle

Collection

Consent-aware ingestion through APIs, webhooks, or uploads with scope-limited keys.

Processing

Transient memory, minimal retention by default, and deterministic routing for sensitive data.

Storage

Encrypted at rest, tenant isolation, and optional customer-managed keys where the deployment calls for them.

Deletion

Ticketed deletion workflows with an evidence chain, with backups pruned on schedule.

Posture, Testing, Deployment

Privacy alignment

Data handling is aligned with GDPR principles, including consent, minimization, and documented privacy flows.

Testing discipline

Threat modeling, secure development checks, and automated dependency and supply-chain scanning are part of the build path.

Deployment options

Standard isolated cloud, private VPC or peering, and hybrid bridges for workloads that need to remain inside an existing environment.

Documentation available under NDA: policies, privacy documentation, subprocessors, and data flow diagrams.

Incident Response

Response is designed around evidence, containment, and communication. The system handles first response where it can, and people enter when judgment is required.

Coverage does not depend on one person being awake, because we are split across US and Italy time zones and the system handles first response.
Customer notification is handled according to regulatory thresholds and contractual obligations.
Root-cause analysis and corrective actions are documented after material incidents.

Shared Responsibility

Auctus Apex

Platform security, logging, and access controls
Encryption, key management, and network posture
Incident response and vulnerability management

Customer

User provisioning and identity configuration
Data classification and least-privilege policies
Approval workflows and retention settings

Security is the part of the work we are least willing to compromise.

If that is the standard you hold your own operation to, that is the conversation.

Start the conversation →