Legal

Compliance Posture

Last updated: June 2026

1. Our position

Org.Tech deploys managed private AI infrastructure inside your AWS account. The deployment is designed to align with the SOC 2 Trust Services Criteria. We treat SOC 2 as an engineering standard that governs how we design and operate - not a marketing claim.

To be precise: Org.Tech does not currently hold a SOC 2 attestation report. There is no third-party audit or certificate in place. We are stating an alignment of design and operating practice, not a certified outcome. Our target path is SOC 2 Type I (controls suitably designed at a point in time), progressing to Type II (controls operating effectively over a sustained period). Both require assessment by a licensed CPA firm - we do not issue those reports ourselves.

We are transparent about this distinction because the people who evaluate us - IT directors, CTOs, and security reviewers - care about the difference, and so do we.

2. Deployment model

Org.Tech deploys managed AI infrastructure inside the client's own AWS account using infrastructure as code. We do not host client data on our infrastructure. This means:

  • Your data stays inside your AWS account and security boundary
  • AI compute runs in your isolated private network, with a private network endpoint connecting to the managed AI inference service - traffic does not traverse the public internet
  • Canadian data residency is available as a configurable option: when enabled, storage, processing, and audit logging are pinned to Canadian regions
  • You retain full ownership and control of the environment
  • Our management access is scoped, time-bounded, and revocable at any time

Because the infrastructure lives in your account, your existing compliance controls - including any SOC 2 program you already operate - extend naturally to the AI platform we deploy. Where you hold a certification, our deployment lands inside your certified boundary rather than requiring its own.

Important distinction: The managed AI inference service (Amazon Bedrock) is an AWS-operated service. Your compute calls it through a private network endpoint inside your isolated network - but the model weights and inference fleet are AWS-managed, not deployed inside your network. What is yours: the data, the prompts, the responses, the audit trail, the encryption keys, and the network path.

3. SOC 2 - what alignment means here

SOC 2 (AICPA) is evidence-centric - an auditor's attestation that controls mapped to the Trust Services Criteria are designed and operating effectively. It is the default expectation in North American vendor reviews.

The deployment provides the technical controls that support a SOC 2 program: encryption, access control, logging, network isolation, identity management. These are necessary but not sufficient. A complete SOC 2 program also requires organizational controls - policies, change management, access reviews, incident response, vendor management, ongoing monitoring - that live with the client or with a future Org.Tech attestation. We do not claim that the deployment alone makes you SOC 2 compliant.

We map our practices to the SOC 2 vocabulary so a North American reviewer asking "are you SOC 2?" receives a documented, honest answer about what is designed, what is operating, and what is not yet audited.

4. What the deployment can provide

The following describes capabilities available in the deployment - scoped by posture tier. Not all capabilities are enabled by default; the Security Posture Questionnaire determines which are activated for each client.

Network isolation and private connectivity

  • AI compute runs inside a dedicated isolated private network (not a shared or default network)
  • Connection to the managed AI inference service uses a private network endpoint - model invocations do not traverse the public internet
  • Network segmentation between application tiers using security groups and network access control lists

Identity and access control

  • Least-privilege IAM roles scoped to named resources
  • Multi-factor authentication available on identity pools (configurable per posture tier)
  • Management access scoped, session-capped, and auditable
  • No hardcoded credentials in deployed infrastructure

Encryption

  • Encryption in transit (TLS) and at rest for all data stores
  • Customer-managed encryption keys available (configurable per posture tier)

Audit and logging

  • Account-level audit logging available, capturing every API call in the client environment (configurable per posture tier)
  • Model invocation logging - every prompt and response auditable
  • Infrastructure as code - all deployments are repeatable, version-controlled, and reviewable

Data residency

  • Canadian data residency is configurable: when enabled, storage, orchestration, and audit logging are pinned to Canadian cloud regions
  • Model inference residency depends on model availability - in-region models (currently Claude Haiku 4.5, Titan Embeddings) keep inference in Canada; frontier models may require cross-region routing, disclosed in the posture questionnaire
  • Compliance-ready posture for PIPEDA and provincial health privacy regimes (PHIPA, PIPA, PHIA) - the architecture supports the accountability and documentation requirements these statutes demand

Availability

  • Infrastructure deployed on AWS managed services with built-in redundancy
  • Monitoring and alerting configured per client environment

Confidentiality

  • Data classified and protected through network segmentation, encryption, and strict access controls
  • No cross-client data exposure - each client operates in their own AWS account

5. Posture tiers

Not every client needs the same security surface. Org.Tech offers three deployment tiers - baseline, standard, and strict - each enabling progressively stronger controls. The Security Posture Questionnaire captures the client's requirements and outputs the committed configuration.

  • Baseline: Isolated private network, private connectivity to the inference service, encryption at rest, IAM least-privilege, infrastructure as code
  • Standard: Adds account-level audit logging, customer-managed encryption keys, MFA on identity pools, Canadian data residency (where model availability permits)
  • Strict: Adds session-capped management access with explicit role assumption, full model-invocation logging, region-pinned inference (in-region models only), and enhanced network controls

Every posture commitment is recorded as a versioned configuration artifact in the client's infrastructure repository - auditable, attributable, and immutable once deployed.

6. What we can provide for vendor reviews

If your organization requires compliance documentation from vendors, we can provide:

  • A controls mapping showing how our deployment practices align with the SOC 2 Trust Services Criteria
  • Completed security questionnaires (SIG, CAIQ, or custom)
  • Architecture diagrams showing data flow and security boundaries - including clear delineation between customer-owned and AWS-managed components
  • Documentation of access controls, operational procedures, and posture configuration
  • The committed posture JSON artifact for the client's deployment

7. What we do not claim

  • We are not SOC 2 certified (Type I or Type II) - we provide technical controls that support the criteria
  • We do not claim the managed AI inference service runs inside your network - it runs in AWS's managed fleet, reached through a private network endpoint you control
  • Canadian data residency, where configured, applies to storage and orchestration; frontier model inference may route through non-Canadian regions when in-region models are unavailable - this is disclosed in the posture questionnaire

8. Contact

For security documentation, controls mapping, the posture questionnaire, or to discuss compliance requirements, contact us at hello@org.tech.