Skip to content

Cloud Security 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 cloud services used or customer requirements

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: shared responsibility, IAM, secrets, IaC, logging, change management, Amazon Connect and Lex. Sandeep AC —
1.0 2026-10-15 Initial effective release. Sandeep AC Sandeep AC

Purpose

This policy defines how Cloudnaut personnel work securely in cloud environments — principally AWS — when designing, building, and supporting systems for customers, and how responsibilities are divided between AWS, the customer, and Cloudnaut.

Scope

All cloud work performed by Cloudnaut personnel, including in customer-owned AWS accounts, and any Cloudnaut-owned cloud accounts. Software delivery controls are in the Secure SDLC Policy; this policy adds cloud-specific requirements.

Shared responsibility

AWS is responsible for security of the cloud (facilities, hardware, and the infrastructure that runs AWS services). Security in the cloud is the account owner’s responsibility. In customer accounts, the customer is the account owner and remains accountable for its accounts, data, identity configuration, and operations. Cloudnaut is responsible for performing its contracted work securely within the access the customer grants.

Responsibility AWS Customer (account owner) Cloudnaut
Physical and infrastructure security of AWS services ✔
AWS Organization, account structure, guardrails (SCPs), root account ✔ Designs or implements only if contracted
Identity provider, federation, issuing access to Cloudnaut ✔ Requests least-privilege access; protects credentials
Security monitoring and response in production ✔ Supports as contracted; reports issues found
Design and code delivered by Cloudnaut (IaC, application, configuration) Approves and accepts ✔ Builds to secure baseline
Data classification and data protection decisions ✔ Implements as specified
Cloudnaut personnel conduct and endpoint security ✔

The responsibility split for each delivery model is in the Engagement Responsibility Model.

Policy

Identity and access

  1. Access to customer AWS accounts uses identities the customer issues — preferably federated or IAM Identity Center users with temporary credentials. Long-lived IAM user access keys are avoided; where the customer requires them, they are stored securely and rotated per customer policy.
  2. Personnel request least-privilege roles for the task; broad administrator access is used only where the customer approves it and only for as long as needed.
  3. Root user credentials of customer accounts are not used or held by Cloudnaut unless the customer requires it in writing.
  4. IAM policies delivered by Cloudnaut follow least privilege: scoped actions and resources, conditions where practical, and no wildcard administrator policies without documented customer approval.
  5. MFA is used for console access as described in the Access Control and Identity Management Policy.

Secrets management

  1. Secrets (passwords, API keys, tokens, private keys) are never committed to source control, embedded in IaC, AMIs, container images, or logs, or shared via chat or email.
  2. Delivered systems use a managed secret store (for example AWS Secrets Manager or SSM Parameter Store SecureString) or the customer’s chosen equivalent, with rotation where supported.
  3. Repository secret scanning and SAST run as described in the Code Security Scanning Policy. A detected secret is treated as exposed: it is rotated and handled as an incident.

Infrastructure as code

  1. Infrastructure is defined in code (Terraform, Terragrunt, AWS CDK, CloudFormation) in the engagement repository, subject to branch protection, peer review, and scanning per the Secure SDLC Policy.
  2. Manual console changes in customer environments are avoided; where necessary (for example during an incident or when the customer asks), they are recorded and reconciled into code.
  3. Remote state files are treated as Confidential, stored encrypted with restricted access, and never committed to repositories.

Secure configuration baseline

Delivered infrastructure applies, unless the customer specifies otherwise: encryption at rest using AWS KMS (AES-256) for supported services and encryption in transit (TLS); private networking and security groups limited to required sources; no public S3 buckets unless the design requires and the customer approves; logging enabled; and tagging per the customer standard. Pre-deployment verification follows the Secure SDLC Policy.

Logging and monitoring

  1. Cloudnaut designs include audit and service logging (for example AWS CloudTrail, CloudWatch Logs, VPC Flow Logs, service access logs) as the customer’s requirements specify.
  2. Operating log monitoring and alert response in customer accounts is the customer’s responsibility unless contracted to Cloudnaut.
  3. Personnel do not disable or alter audit logging in customer accounts.

Change management

  1. Changes to customer environments follow the customer’s change process. Where none exists, changes go through a reviewed pull request and the Engagement Lead’s approval before deployment.
  2. Production deployments are performed through pipelines or by approved personnel at agreed times, with a rollback plan for material changes.
  3. Emergency changes are recorded and reviewed afterwards.

Amazon Connect and Amazon Lex engagements

In addition to the above, contact center work:

  1. Treats call recordings, transcripts, chat logs, and contact attributes as Restricted where they may contain personal or payment data; Cloudnaut personnel do not export them outside the customer account.
  2. Designs encryption of recordings and transcripts with KMS keys, and data retention as the customer specifies.
  3. Configures Lex bots and contact flows to avoid capturing payment card data or other sensitive data unless the customer has a compliant design for it (for example DTMF masking or a certified payment integration).
  4. Uses least-privilege IAM roles for Lambda functions and integrations invoked by contact flows.
  5. Tests with synthetic data rather than real customer contacts unless the customer approves otherwise.

Exceptions

Deviations from the baseline require customer approval recorded in the engagement record, and management approval where they affect Cloudnaut’s obligations.

Records

IaC repositories and pull requests, pipeline logs, pre-deployment checklists, customer change approvals, access requests and removal evidence, and exception approvals.