Controlled Access Model

This page explains how CTO2B controls access to your production environment.
It is written to answer the evidence a security questionnaire or audit
usually asks for, such as "production systems can only be remotely accessed
by authorized employees via approved methods".

Overview

The CTO2B access model rests on four principles: approved access paths,
authorization, time-bound access, and auditability. Our team
accesses your environment only in response to a support request or during
incident handling — never on a persistent, standing basis.

For privacy reasons we do not provide a roster of individual employee names
and email addresses as standard evidence. We provide role- and process-based
evidence plus audit logs showing that only authorized identities accessed
production, and only through approved methods. See the FAQ below if your
auditor requires named individuals.

Approved Access methods

There is no direct access to your environment outside these paths:

Access proxy (Teleport-based)
Cloud IAM federated roles — no shared or static credentials

Access governance

CTO2B maintains no persistent access to customer production environments.
Access is granted just-in-time only when required, and expires
automatically.
Access requires approval through an internal request process, triggered by
either a Service Desk ticket raised by you and approved by a line
manager, or incident response approved by a line manager or incident
manager.
Access is removed or expires per the time-bound policy, and every grant is
auditable.
Eligibility is limited to the CTO2B SRE group, managed through our internal
identity and access management process (joiner/mover/leaver plus periodic
reviews).

Access levels (least privilege)

Level	Scope
Business as Usual (read-only)	Non-critical data, read-only — excludes secrets and direct access to sensitive data stores such as databases
Elevated (PowerUser)	Used only when required for implementation or incident resolution, under the same approval and time-bound controls

Requesting audit evidence

To request an evidence extract, raise a Service Desk ticket and state a
specific audit window, for example "last 7 days". A narrow, explicit window
is the fastest route to a response. Evidence is returned through a secure
channel.

Depending on the request and the window, CTO2B can provide:

A description of the approved access methods (access proxy plus federated
roles)
The roles and groups used for customer access, and membership counts
A description of the request and approval workflow and the time-bound
access controls
Scoped access logs showing who accessed an environment, when, and via
which approved method

FAQ

Why does CTO2B not share a names-and-emails roster by default?

A roster is usually not necessary to meet the intent of the control. The
combination of approved access methods, access governance, and audit logs is
stronger, verifiable evidence while exposing less personal data.

Can you provide named individuals if our auditor insists?

Yes. If an auditor explicitly requires named individuals, we can discuss a
minimal, purpose-limited disclosure under appropriate confidentiality and
secure-sharing controls. In most cases the role, process, and log evidence
above is sufficient.

How do I start an audit request?

Raise a Service Desk ticket describing what the auditor asked for and the
audit window you need covered.