Engagement Access Isolation Policy¶
Classification: Internal
Document status: Effective
Version: 1.3
Owner: Management / Security Owner
Review cycle: Annual; interim revision upon material change to prime contractor or customer access models
Document control¶
| Role | Name |
|---|---|
| Prepared by | Management / Security Owner (Cloudnaut) |
| Reviewed by | Nidhi Jain (third-party reviewer) |
| Approved by | Sandeep AC |
Revision history¶
| Version | Date | Summary | Reviewed by | Approved by |
|---|---|---|---|---|
| 0.9 | 2021-03-14 | Draft for third-party review prior to first effective release. | Nidhi Jain (third party) | — |
| 1.0 | 2021-06-18 | Initial effective release. | Nidhi Jain (third party) | Sandeep AC |
| 1.0 | 2024-03-11 | Scheduled annual review; clarifications and cross-references (retained at version 1.0). | Nidhi Jain (third party) | Sandeep AC |
| 1.1 | 2025-11-26 | Multiple workstream model; access-creep prevention; audit and tagging evidence. | Nidhi Jain (third party) | Sandeep AC |
| 1.2 | 2026-05-19 | No cross-staffing across workstreams; reassignment revocation; dedicated endpoint when required. | Nidhi Jain (third party) | Sandeep AC |
| 1.3 | 2026-05-19 | Generic workstream terminology; removed customer- or program-specific examples from policy body. | Nidhi Jain (third party) | Sandeep AC |
Purpose¶
This policy defines how Cloudnaut separates access across customers, contracts, and concurrent workstreams—including staffing, credential, endpoint, and network isolation when more than one commercial path applies to the same end customer. It also describes how to evidence that separation for customers, partners, and prime contractors.
Scope¶
This policy applies when:
- Cloudnaut maintains more than one contract or statement of work with the same end customer, or
- Cloudnaut performs work as a subcontractor under a prime contractor while also holding (or having held) a direct contract with that customer.
Workstream means a distinct delivery path with its own governance, credentials, and scope—for example a direct customer contract versus a subcontract under a prime. Labels are defined per engagement in the access plan; this policy does not prescribe vendor- or program-specific names.
It complements:
- Engagement Role Boundaries and Security Governance Policy — delegated authority and governance role limits.
- Endpoint Security Policy — encryption, anti-malware, and host firewall on corporate endpoints used for customer work.
Policy¶
Personnel use only accounts, repositories, credentials, VPN paths, and permissions approved for the active workstream. Credentials, sessions, or access obtained under one workstream are not used for another workstream for the same customer unless expressly authorized in writing. Concurrent staffing on two workstreams for the same customer is prohibited unless the engagement access plan documents a permitted exception (see Concurrent workstreams (same customer)).
Concurrent workstreams (same customer)¶
When the same end customer has two or more active workstreams (for example a direct Cloudnaut contract and a subcontract under a prime), Cloudnaut enforces operational and credential isolation between them.
Staffing¶
No consultant is assigned to two workstreams for that customer at the same time. Staffing plans and records must show one workstream per person unless management documents a one-time reassignment (below)—not ongoing dual assignment.
Reassignment¶
If a consultant must move from one workstream to another for the same customer:
- Before work begins on the new workstream, complete full revocation of access tied to the prior workstream: cloud identities and roles, group membership, VPN or Zero Trust profiles, bastion keys, repository and CI/CD credentials, and break-glass or elevated roles.
- Retain evidence of revocation (ticket, identity export, access-removal confirmation).
- Issue credentials only for the new workstream’s governance path.
- Record reassignment and revocation in staffing and access records.
If revocation cannot complete before the start date, assign an alternate consultant who never held conflicting privileged access on the prior workstream.
Dedicated endpoint (when required)¶
The engagement access plan states whether a workstream requires a dedicated corporate laptop (or equivalent managed endpoint). A dedicated device is required when:
- the plan designates physical endpoint separation between workstreams, or
- a consultant reassigns from one workstream to another for the same customer and the prior endpoint could retain artifacts from the old path.
The dedicated endpoint is not shared as a daily driver across conflicting workstreams. Before use, it must not retain local repository clones, cached credentials, saved VPN profiles, browser sessions, or cloud CLI profiles from the prior workstream unless they are re-provisioned fresh for the new workstream identity only. The device meets the Endpoint Security Policy before customer access.
Relationship to other sections¶
Isolation layers across workstreams and Preventing access creep apply in addition to staffing and endpoint rules above.
Elevated access overlap¶
Where the same person would retain elevated or production-privileged access from one workstream while starting another for the same customer, Cloudnaut requires either:
- (a) documented revocation of the prior elevated access with evidence retained, or
- (b) assignment of an alternate consultant without the conflicting access.
The choice is recorded in staffing or access records. Informal discipline alone is insufficient.
Isolation layers across workstreams¶
When multiple workstreams exist for one customer, Cloudnaut maps controls to the layers below. Contract-specific names (IAM role names, account IDs, tag keys, repository hosts) come from the customer, partner, or prime written standard and the engagement access plan—not from this policy.
| Isolation layer | Workstream under direct contract with the customer | Workstream under subcontract with a prime |
|---|---|---|
| Identity | Identities and roles governed by the direct contract (customer- or Cloudnaut-provisioned per the SOW). | Identities and roles issued for the subcontract SOW only, governed by the prime’s access model. Do not reuse direct-contract principals on subcontract tasks unless authorized in writing. |
| Governance | Change control and approvals per the MSA / SOW (or equivalent) with the customer. | Scope and approvals per the subcontract and prime rules; prime requirements override informal habits from the direct path when they conflict. |
| Data and workload | Resources in accounts, subscriptions, or network segments designated for the direct contract. | Resources in separate accounts or segments when the contract or prime requires separation from the direct-contract footprint. |
| Personnel | Team bound by customer NDAs and company policy; no concurrent assignment on another workstream for that customer (see Concurrent workstreams). | Separate staffing; subcontract-specific acknowledgements before credentials; dedicated endpoint when the access plan requires it; no reuse of direct-contract IAM, VPN, or endpoint artifacts. |
Source code and CI/CD are segregated per workstream using GitHub organization and GitLab group/project boundaries (see Technical controls).
Preventing access creep¶
To show that credentials from one workstream are not used for another, Cloudnaut applies the following as required by the customer or prime (depth documented in the engagement access plan):
Resource tagging¶
Infrastructure and workloads carry workstream-identifying tags mandated by the customer or prime—for example a contract code, project ID, or Workstream=<identifier> key pair. Each workstream uses a distinct tag set. Tags support cost allocation, policy conditions, and audit listing by workstream.
Evidence: tag compliance exports, infrastructure-as-code plans showing tags, or organization tag-policy reports.
Access auditing¶
Where the customer environment provides audit logs (for example AWS CloudTrail, Azure Activity Log, or GCP Cloud Audit Logs), logs are enabled and retained per contract. Review and export show which principal acted in which scope. Access analyzer or equivalent tools are used where deployed to detect unintended cross-scope access.
Evidence: saved audit queries, exports, and analyzer findings stored with engagement records.
Network separation¶
Use separate VPN profiles, Zero Trust segments, bastion paths, or customer-provided access routes per workstream so session routing is not shared. Dedicated endpoints apply when the access plan requires them (see Dedicated endpoint). Session and VPN logs supplement cloud audit where available.
Repository and build identity¶
CI/CD roles, pipeline identities, and deployment keys are scoped per workstream (separate pipeline environments, secrets, or cloud roles) so automation cannot deploy one workstream’s assets with another’s credentials without a deliberate, reviewed change.
Technical controls¶
- Customer separation uses GitHub organization and GitLab group, project, and repository boundaries per workstream.
- Repositories and identities are provisioned per engagement workstream where practicable.
- Access follows need-to-know and the engagement role definition.
- Personnel escalate when overlapping or ambiguous access could violate contract separation.
- Reviews cover privileged roles (administrator, break-glass, production write), not only repository read access.
- For cloud environments: IAM (or equivalent), federation trust, organization guardrails, and tag-based ownership checks when one customer hosts multiple workstreams.
Records¶
Typical evidence includes:
- Engagement access plan naming workstreams and required controls (tagging, endpoint separation, audit depth).
- Organization and repository membership, invitations, approvals, and revocation at workstream end or reassignment.
- Identity exports showing distinct principals per workstream and revocation of conflicting access.
- Tagging exports or infrastructure-as-code showing workstream tags.
- Audit log and access-analyzer exports for the engagement period.
- VPN, bastion, or Zero Trust confirmations when network separation is in scope.
- Dedicated endpoint provisioning or asset record when required; attestation that prior-workstream credentials and profiles are absent.
- Staffing roster showing no concurrent dual workstream assignment, or reassignment packet with revocation evidence.
- Delivery lead assignment per workstream.