Access Control and Identity Management Policy¶
Organization: Cloudnaut Technologies LLP
Classification: Internal
Document status: Effective
Version: 1.0
Owner: Management / Security Owner
Effective date: 2026-10-15
Review cycle: Annual; interim revision upon material change to identity platforms or customer access models
Document control¶
| Role | Name |
|---|---|
| Prepared by | Management / Security Owner (Cloudnaut) |
| Reviewed by | Sandeep AC |
| Approved by | Sandeep AC |
Revision history¶
| Version | Date | Summary | Reviewed by | Approved by |
|---|---|---|---|---|
| 0.1 | 2026-10-15 | Initial draft: account lifecycle, MFA, privileged access, access reviews. | Sandeep AC | — |
| 1.0 | 2026-10-15 | Initial effective release. | Sandeep AC | Sandeep AC |
Purpose¶
This policy defines how access to Cloudnaut systems and to customer systems used by Cloudnaut personnel is requested, approved, provisioned, reviewed, and removed, so that access is limited to what each person needs for their current role.
Scope¶
- Cloudnaut-managed identities: corporate email and collaboration accounts, source-control accounts and organization memberships (GitHub, GitLab), scanning and CI/CD tools (for example Snyk, Sonar), endpoint protection console, and any Cloudnaut-owned cloud accounts.
- Customer-issued identities: accounts, roles, VPN profiles, and keys the customer issues to Cloudnaut personnel. The customer owns and administers these identities and their controls; Cloudnaut’s obligations are to request only what is needed, use them only for the engagement, protect them, and request their removal when no longer needed.
Separation between customers and between workstreams of the same customer is governed in detail by the Engagement Access Isolation Policy and is not repeated here.
Roles and responsibilities¶
| Role | Responsibilities |
|---|---|
| Security Owner | Administers Cloudnaut-managed identities; performs access reviews; holds the access register. |
| Engagement Lead | Requests and approves engagement access; requests removal from the customer; confirms customer access lists during reviews. |
| Management | Approves privileged access to Cloudnaut-managed systems and exceptions. |
| Personnel | Use only their own accounts; protect credentials; enable MFA; report suspected compromise. |
Policy¶
Principles¶
- Least privilege and need-to-know: access is the minimum required for the current role and engagement.
- Individual accountability: every person uses a named individual account. Shared accounts are not used unless a platform cannot support individual accounts; any shared credential is held in an approved secret manager, has a named owner, and is rotated when a holder leaves.
- Separation: access for one customer or workstream is never used for another (see the Engagement Access Isolation Policy).
Access lifecycle (joiner, mover, leaver)¶
| Stage | Requirement |
|---|---|
| Request and approval | Access is requested by the Engagement Lead or line manager stating system, role, and reason, and approved before provisioning. Customer-issued access follows the customer’s request process. Approvals are recorded in Cloudnaut’s internal access records. |
| Provisioning | Provisioned only after screening, agreements, and training are complete (see HR Security Policy). |
| Change (mover) | Access no longer needed for the new role is removed before or when new access is granted. |
| Removal (leaver) | Access is disabled on or before the last working day, immediately on involuntary termination, and when an engagement ends. Removal is evidenced (for example audit log entry or membership export). |
Authentication and MFA¶
- MFA is required for Cloudnaut corporate accounts, source-control accounts (GitHub, GitLab), CI/CD and scanning tool accounts, endpoint protection console, and cloud console access, wherever the platform supports it. Where a customer-issued identity supports MFA, it is enabled unless the customer’s identity system enforces its own controls.
- Phishing-resistant methods (security keys or platform authenticators) are preferred for privileged accounts.
- Passwords are unique per system, generated or long passphrases, and stored only in an approved password manager. Unexpected MFA prompts are denied and reported.
- Source-control access uses individual SSH keys or scoped, expiring personal access tokens registered to the engagement identity.
Privileged access¶
- Administrative access to Cloudnaut-managed systems is limited to named individuals approved by management, and used only for administrative tasks.
- Privileged or production access in customer environments is used only as the customer authorizes, preferably via time-bound or just-in-time mechanisms the customer provides, and is removed when the task ends.
- Break-glass or root credentials are not held by Cloudnaut personnel unless the customer requires it in writing; if held, they are stored in the customer-approved vault and every use is reported to the customer.
- Removal of elevated access is evidenced (for example cloud IAM change record, group-membership export, or customer confirmation).
Access reviews¶
| Scope | Frequency | Performed by | Evidence |
|---|---|---|---|
| Privileged access to Cloudnaut-managed systems | Quarterly | Security Owner | Review record with removals |
| All Cloudnaut-managed accounts and org memberships | Semi-annually | Security Owner with Engagement Leads | Membership exports, removals |
| Customer-issued access held by Cloudnaut personnel | At engagement milestones and at least semi-annually, or as the customer requires | Engagement Lead | List compared with staffing; removal requests sent to customer |
Access found to be unnecessary is removed and the removal recorded.
Exceptions¶
Exceptions (for example a platform that cannot support MFA) are approved by management, recorded with compensating controls and an expiry date, and reviewed at expiry.
Records¶
Access requests and approvals, access register, review records, removal evidence, and exceptions, held internally.