Security and trust for AI outcomes

CMD+RVL builds narrow, evidence-backed AI outcomes for teams that need to explain every number, source, and handoff. Security is part of that operating model: deployment fit, access boundaries, evidence retention, and sub-processor visibility are discussed before work starts.

Each engagement is scoped around a specific workflow and a specific set of evidence. When a client-cloud deployment is approved, credentials, network controls, and data boundaries follow the client environment. Managed deployments use scoped access and reviewed handling for the data required to operate the agreed workflow.

Deployment

• Deployment pattern: Docker on AWS or Azure, client-approved cloud, or managed cloud depending on the security review and operating model.
• Data handling: Scope data access to the agreed outcome and document what is processed, retained, and excluded.
• Protection baseline: Encrypt data and metadata in transit and at rest where storage is part of the deployment.

Current Security Position

We use the controls below as the current baseline for scoped outcome work.

AWS Security Practices

For AWS-managed work, we use IAM roles and policies, VPC and network boundaries, security groups, encrypted storage, and least-privilege access.

Client Environment Controls

When a client-hosted deployment is approved and scoped, the work follows the approved cloud, identity, logging, and data-access model rather than asking teams to bypass their existing controls.

Data Protection

We define the required evidence, data extracts, metadata, and retention period during scoping. Encryption is used in transit and at rest for data and metadata handled by the deployment.

Access Controls

Access is role-based, scoped to the engagement, and reviewed against the workflow being operated. DDQ responses and security packages can include the deployment details relevant to the requested review.

Security Roadmap

We publish roadmap items when they affect procurement, review, or customer diligence.

SOC 2 Readiness

SOC 2 Type I target: Q3 2026, with quarterly readiness checkpoints.

Readiness work includes policy documentation, control ownership, evidence collection, vendor review, and audit preparation. We will share the formal report status as it becomes available.

Penetration Testing

External penetration testing is part of the readiness plan. We will publish a short verification summary after the first completed assessment.

The initial assessment will be performed by an independent third party. Findings will be tracked through remediation, and repeat testing will be scheduled around material platform or deployment changes.

Sub-processors

We publish a concise, current list and notify on changes. Review the latest details on our sub-processors page.

Verification Notes

For key feeds and features, we post brief verification or methodology notes so teams can see coverage, freshness, and known gaps.