Skip to content

Instantly share code, notes, and snippets.

@fontvu

fontvu/lld.md

Created June 18, 2026 10:16
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save fontvu/d2375c1afe616055d56eeb691f3cc844 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save fontvu/d2375c1afe616055d56eeb691f3cc844 to your computer and use it in GitHub Desktop.
Download ZIP
LLD Template — multi-cloud architectural blueprint
Raw
lld.md

📐 Low Level Design (LLD) Template

Purpose: This document serves as the centralized architectural blueprint for your application, capturing low-level design decisions, infrastructure requirements, security controls, and operational readiness criteria.

📋 Version Control

Version Author(s) Comments Date
0.1 📝 Initial Draft DD/MM/YYYY
1.0 🔧 Multi-cloud rework: AWS/GCP/Alibaba Cloud examples; aligned to 3-team model (SWE / SRE / Security); added AI Security, Data Migration & glossary sections; proofread and normalized formatting 2026-06-17

🧑‍💼 Section Completion Convention

Each section in this template identifies the responsible team(s) (SWE / SRE / Security) and should be filled with the following metadata tracked per section:

Field Description
Status ✅ Done / 🔄 In progress / ⬜ Not started
Owner Team or individual responsible for completion
Reviewer Team lead or security champion who signs off

💡 Tip: Append status markers to section headers during authoring, e.g. ## 1. Solution Design Architecture [✅ Done]. Remove before final publication.

📖 Introduction

The objective of this document is to define the low-level architecture design of a solution and serve as a centralized design repository (a.k.a. blueprint) for an application. This blueprint includes design considerations such as:

  • Architectural context & model
  • Existing & target architecture
  • Data flow interactions between technology stacks
  • Infrastructure & security control requirements
  • High availability, hosting locations, integration & automation design
  • Operational readiness: contacts, escalation procedures, impacted teams

🗂️ Table of Contents

1. Solution Design Architecture

This section is required to be completed by Software Engineering team. 🏗️

💡 Tip: Include diagrams (PlantUML, Mermaid, draw.io) wherever possible. Visual docs beat text walls.

1.1 Solution Description

Describe the purpose of the solution, highlighting key design elements. Use diagrams where necessary.

Enter your answer here.

Example:

Customer portal web application hosted on cloud. Users access https://portal.example.com through a public load balancer. The frontend is served by container workloads in AWS EKS / GCP GKE / Alibaba ACK. The backend APIs connect to managed relational database, Redis cache, object storage, and centralized logging. All traffic uses TLS 1.3, private subnets for workloads, and no direct public database access.

1.2 System Use Case Diagram

Use case diagrams show key actions or events that define the interaction between an actor, either human or other external system, and the system.

Enter your answer here.

Example:

Actors: Customer, Admin User, Payment Gateway, Notification Service. Main use cases: Register/Login, Submit Application, Upload Document, Pay Fee, View Status, Send Email/SMS Notification, Generate Report, Audit User Activity.

1.3 Data Flow Diagram

Example of Data Flow diagram is shown below.

(Attachment placeholder) Provide a data flow diagram of the overall solution.

Example:

  1. Customer browser -> Public DNS -> Cloud Load Balancer/ALB/SLB -> Web/API tier.
  2. Web/API tier -> Managed database for persistent data.
  3. Web/API tier -> Redis cache for session/cache data.
  4. Web/API tier -> Object storage for uploaded documents.
  5. Web/API tier -> Message queue for asynchronous processing.
  6. Worker service -> Notification service for email/SMS.
  7. All tiers -> Centralized logging/monitoring service.

2. Technology Architecture

This section is required to be completed by Software Engineering team in collaboration with Site Reliability Engineering (SRE) team. ☁️

2.1 Production Environment

High level diagram that consists of application and infrastructure components and illustrates how they interact.

2.1.1 Traffic Flow

  1. Traffic 1 –
  2. Traffic 2 –
  3. Traffic 3 –
  4. Traffic 4 –
  5. Traffic 5 –
  6. Traffic 6 –
  7. Traffic 7 –
  8. Traffic 8 –

🛑 Note: Traffic flow from infrastructure to automation and infrastructure-based toolsets such as VDI/CI/CD tool set/Logging/AD/Identity Providers is not captured in the blueprint.

Example:

  1. Internet user -> DNS -> AWS ALB/GCP HTTPS Load Balancer/Alibaba SLB -> Web pods.
  2. Web pods -> API pods through internal service mesh/private VPC.
  3. API pods -> RDS/Cloud SQL/ApsaraDB using TLS on port 3306/5432.
  4. API pods -> ElastiCache/Memorystore/Alibaba Redis on port 6379.
  5. API pods -> S3/GCS/OSS using HTTPS.
  6. Worker pods -> SQS/Pub/Sub/Alibaba MQ for job processing.
  7. App logs -> CloudWatch Logs/Cloud Logging/Alibaba Log Service.
  8. Admin user -> VPN/IAP/Bastionhost -> Kubernetes/API control plane.

2.2 Non-Production Environment

High level diagram that consists of application and infrastructure components and illustrates how they interact.

2.2.1 Traffic Flow

  1. Traffic 1 –
  2. Traffic 2 –
  3. Traffic 3 –
  4. Traffic 4 –
  5. Traffic 5 –
  6. Traffic 6 –
  7. Traffic 7 –
  8. Traffic 8 –

🛑 Note: Traffic flow from infrastructure to automation and infrastructure-based toolsets such as VDI/CI/CD tool set/Logging/AD/Identity Providers is not captured in the blueprint.

Example:

  1. Test users -> DNS uat.example.com -> UAT load balancer -> UAT web pods.
  2. UAT web pods -> UAT API pods in private subnets.
  3. UAT API pods -> UAT managed database with masked synthetic data.
  4. CI/CD pipeline -> Container registry -> UAT cluster deployment.
  5. Test scripts -> UAT API endpoint for regression testing.
  6. UAT logs -> Central logging workspace/project/account.
  7. Admin engineers -> VPN/IAP/Bastionhost -> UAT bastion/debug pods.
  8. Monitoring agent -> Cloud monitoring service for alerts and metrics.

3. Infrastructure Provisioning

This section is required to be completed by Software Engineering team in collaboration with Site Reliability Engineering (SRE) team. 🏭

3.1 Infrastructure

3.1-1 Does the solution require Internet connectivity? Elaborate, if yes.

Enter text here. Please ensure connectivity requirements adhere to network segmentation standards and IT security policies.

AWS Example: The solution requires Internet connectivity for outbound API calls to external services and customer-facing web traffic. The application will be deployed in AWS us-east-1 with NAT Gateway for outbound traffic and Application Load Balancer for inbound HTTPS traffic on port 443.

GCP Example: The solution requires Internet connectivity for user-facing applications. The deployment will use GCP us-central1 with Cloud Load Balancing for HTTPS traffic and Cloud NAT for outbound connectivity.

Alibaba Cloud Example: The solution requires Internet connectivity with Alibaba Cloud cn-hangzhou region. ALB (Application Load Balancer) will handle HTTPS traffic and EIP (Elastic IP) with NAT Gateway for outbound connectivity.

3.1-2 Is the solution latency sensitive or does the solution require significant consumption of WAN bandwidth? Elaborate if yes.

Enter text here. Please consult Site Reliability Engineering (SRE) team if solution will consume significant WAN bandwidth to avoid slowness or disruption to business.

AWS Example: The solution is latency-sensitive with sub-100ms response time requirement. AWS Direct Connect (1 Gbps) will be used to establish dedicated network connection from on-premises data center to AWS us-east-1. Traffic will use private VPC peering for cross-region replication to us-west-2.

GCP Example: The solution requires low-latency connectivity (<50ms) between microservices. Google Cloud Interconnect (10 Gbps) will connect on-premises to GCP us-central1. Cloud CDN will be enabled for static assets to reduce latency.

Alibaba Cloud Example: The solution requires WAN bandwidth of 500 Mbps for data synchronization. Alibaba Cloud Express Connect (2 Gbps) will link Hangzhou and Shanghai regions. SLB (Server Load Balancer) will distribute traffic across availability zones.

3.1-3 Does the solution connect to an external SaaS service provider including third-party hosting service? Elaborate if yes.

Enter text here. Ensure the external SaaS service provider has been cleared internally from a process governance perspective and meets security requirements.

Example: The solution integrates with external SaaS providers: (1) SendGrid for email delivery, (2) Okta for identity federation, (3) Snowflake for analytics. All connections use TLS 1.3 with mutual TLS authentication. API keys are stored in cloud-native secret manager (AWS Secrets Manager / GCP Secret Manager / Alibaba Cloud KMS).

3.1-4 Does the solution deploy or require its own proprietary database platform? Elaborate if yes.

Enter text here. If proprietary database platform is required, please consult Site Reliability Engineering (SRE) team on this.

AWS Example: The solution requires MongoDB (self-managed on EC2). MongoDB 6.0 will be deployed on m5.xlarge EC2 instances in Multi-AZ configuration with EBS encryption. Automated backups stored in S3 with 30-day retention.

GCP Example: The solution uses CockroachDB (self-hosted on GKE). CockroachDB cluster runs on GKE with persistent disks enabled for data persistence. Encryption at rest enabled via GCP Customer-Managed Encryption Keys (CMEK).

Alibaba Cloud Example: The solution requires Apache Cassandra running on ECS instances. Cassandra 4.0 deployed with 3-node cluster across 2 availability zones. OSS buckets used for periodic backups.

3.1-5 Does the application require backup services? If yes, elaborate on which components and tiers of the solution require backup as well as suggested backup schedule.

Enter text here. Backup is required to support business continuity and disaster recovery plan. Business owner should work with Site Reliability Engineering (SRE) team on this.

AWS Example: Backup services required for all production workloads:

  • RDS MySQL: Automated snapshots daily with 35-day retention
  • EC2 instances: AMI creation weekly with 8-week retention
  • EBS volumes: Snapshots every 6 hours with 7-day retention
  • S3: Versioning enabled + cross-region replication
  • Backup Vault with 1-year retention for compliance

GCP Example: Backup strategy:

  • Cloud SQL: Automated backups enabled with point-in-time recovery (30 days)
  • Compute Engine: Scheduled snapshots (daily) with 21-day retention
  • Persistent Disks: Incremental snapshots every 4 hours
  • Cloud Storage: Object versioning + lifecycle management (90 days)

Alibaba Cloud Example: Backup implementation:

  • ApsaraDB: Automated backups daily with 30-day retention
  • ECS: Image backups weekly with 4-week retention
  • OSS: Versioning + cross-region replication
  • Backup plan: 8-hour interval for critical data, 24-hour for non-critical

3.1-6 Does the application have any High Availability (HA) requirements for resiliency purpose? Elaborate if yes.

Enter text here. High Availability here references to solution/system/component level of redundancy and resiliency consideration.

AWS Example: HA requirement of 99.95% uptime. Multi-AZ deployment across us-east-1a and us-east-1b:

  • Application tier: Auto Scaling Group with 3 instances minimum
  • Database: RDS Multi-AZ with read replica in us-east-1c
  • Load balancer: Application Load Balancer with cross-zone load balancing
  • Cache: ElastiCache Multi-AZ cluster
  • DNS: Route 53 health checks with automatic failover

GCP Example: HA requirement of 99.99% uptime. Regional deployment across us-central1-a, us-central1-b, us-central1-c:

  • GKE cluster: Regional cluster with 3 control plane nodes
  • Workloads: Managed instance groups with minimum 2 instances per zone
  • Database: Cloud SQL failover replica in different zone
  • Load balancing: Global HTTP(S) Load Balancer with managed instance groups

Alibaba Cloud Example: HA requirement of 99.9% uptime. Zone redundancy across cn-hangzhou-a and cn-hangzhou-b:

  • ECS: Auto Scaling Group with instances in multiple availability zones
  • RDS: Primary + secondary instance in different zones
  • SLB: Multi-zone deployment with health checks
  • OSS: Cross-region replication enabled

3.1-7 Does the application require a Disaster Recovery (DR) set up? Elaborate if yes (including the region for this setup).

Enter text here. DR setup would typically reference to setting up identical solution in different approved regions within the same cloud provider.

AWS Example: DR setup with us-west-2 as secondary region:

  • Primary: us-east-1 (Active)
  • Secondary: us-west-2 (Warm standby)
  • Database: Aurora Global Database with cross-region replication
  • S3: Cross-region replication configured
  • Route 53 health checks trigger failover
  • RPO: 15 minutes, RTO: 1 hour

GCP Example: DR using multi-region deployment:

  • Primary: us-central1
  • Secondary: europe-west1
  • Cloud SQL: Failover replica in different region
  • Cloud Storage: Multi-region bucket with versioning
  • DNS: Geo-political policy routing for failover
  • RPO: 5 minutes, RTO: 30 minutes

Alibaba Cloud Example: DR across cn-hangzhou and cn-shanghai:

  • Primary: cn-hangzhou
  • Secondary: cn-shanghai
  • ApsaraDB: Cross-region replication
  • OSS: Cross-region replication with MFA delete
  • DNS: GSLB (Global Server Load Balancer) for failover
  • RPO: 30 minutes, RTO: 2 hours

3.2 Internet and External Third-Party Connectivity

Software Engineering team to include Pull Request (PR) details into below table, including any external domain(s) to be connected.

Enter your answer here.

Example (AWS):

External Service Domain / URL Purpose Port / Protocol Allowlisted By
SendGrid api.sendgrid.com Transactional emails 443/TCP SRE team via AWS Security Group
Stripe api.stripe.com Payment processing 443/TCP SRE team via AWS Security Group
Okta *.okta.com Identity federation 443/TCP SRE team via AWS Security Group

Example (GCP):

External Service Domain / URL Purpose Port / Protocol Allowlisted By
Twilio api.twilio.com SMS notifications 443/TCP SRE team via GCP Firewall Rule

Example (Alibaba Cloud):

External Service Domain / URL Purpose Port / Protocol Allowlisted By
Alipay openapi.alipay.com Payment API 443/TCP SRE team via Alibaba Cloud Security Group

3.3 Network Security Rule Requests

Software Engineering team to update all relevant cloud firewall (AWS Security Groups / GCP Firewall Rules / Alibaba Cloud Security Groups) details into below section in code or table format as below.

Security Best Practice: Apply principle of least privilege. Avoid wildcard CIDR blocks (0.0.0.0/0) for egress unless absolutely necessary. Specify exact destination IP ranges or service endpoints.

AWS Security Group Rules (Terraform Format - Prod)

Enter text here. Example:

resource "aws_security_group" "app_sg" {
  name        = "app-security-group-prod"
  description = "Security group for application servers"
  vpc_id      = var.vpc_id

  ingress {
    description = "HTTPS from load balancer"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }

  egress {
    description = "Outbound HTTPS to specific AWS services"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]  # Internal only, or use VPC endpoints
  }
  
  # Avoid: egress to 0.0.0.0/0 unless justified and documented
}

GCP Firewall Rules (Terraform Format - Prod)

Enter text here. Example:

resource "google_compute_firewall" "app_firewall" {
  name    = "app-firewall-prod"
  network = var.network_name

  allow {
    protocol = "tcp"
    ports    = ["443", "8080"]
  }

  source_ranges = ["10.0.0.0/16"]
  target_tags   = ["app-server"]
}

Alibaba Cloud Security Group Rules (Terraform Format - Prod)

Enter text here. Example:

resource "alicloud_security_group" "app_sg" {
  name        = "app-security-group-prod"
  description = "Security group for application servers"
  vpc_id      = var.vpc_id
}

resource "alicloud_security_group_rule" "https_ingress" {
  type              = "ingress"
  ip_protocol       = "tcp"
  nic_type          = "intranet"
  security_group_id = alicloud_security_group.app_sg.id
  cidr_ip           = "10.0.0.0/16"
  port_range        = "443/443"
  priority          = 1
}

Table format (Prod)

Data Flow No. Source Destination Port(s) Traffic Direction Cloud Provider Remark
Traffic 1 [VPC CIDR:] [Security Group:] [VPC CIDR:] [Security Group:] TCP/443, TCP/8080 e.g. Bi-directional AWS Security Groups / GCP Firewall Rules / Alibaba Cloud Security Groups

Table format (Non-Prod)

Data Flow No. Source Destination Port(s) Traffic Direction Cloud Provider Remark
Traffic 1 [VPC CIDR:] [Security Group:] [VPC CIDR:] [Security Group:] TCP/443, TCP/8080 e.g. Bi-directional AWS / GCP / Alibaba Cloud

3.4 External DNS Records

Requester to indicate any external DNS records into below section.

Enter your answer here.

Example:

Record Name Type TTL Value Description
portal.example.com A 300 12.34.56.78 Public-facing web portal (Cloud Load Balancer VIP)
api.example.com CNAME 300 alb-prod-123456.elb.amazonaws.com Public API endpoint
www.example.com CNAME 600 portal.example.com WWW redirect
cdn.example.com CNAME 600 d1234.cloudfront.net CDN for static assets

AWS Example: Route 53 public hosted zone, alias records to CloudFront/ALB. DNS validation through ACM.

GCP Example: Cloud DNS public zone, record sets with geo-routing policy for multi-region deployment.

Alibaba Cloud Example: Alibaba Cloud DNS public zone, weighted routing policy with health check for multi-region load balancing.

3.5 Internal DNS Records

Requester to indicate associated internal DNS records into below section.

Enter your answer here.

Example (AWS):

Record Name Type Value Description
app.internal.example.com A 10.0.12.34 Internal ALB endpoint (Route 53 Private Hosted Zone)
db.internal.example.com CNAME database.cluster-xxx.region.rds.amazonaws.com RDS cluster endpoint
redis.internal.example.com CNAME redis-cluster.xxxxxx.region.cache.amazonaws.com ElastiCache endpoint

Example (GCP):

Record Name Type Value Description
app.internal.example.com A 10.0.12.34 Internal L4 ILB (Cloud DNS Private Zone)
db.internal.example.com CNAME projects/xxx/locations/us-central1/connections/... Cloud SQL Private Service Connect endpoint

Example (Alibaba Cloud):

Record Name Type Value Description
app.internal.example.com A 172.16.0.10 Internal SLB (Private Zone in Alibaba Cloud DNS)
db.internal.example.com CNAME rm-xxxxx.mysql.rds.aliyuncs.com ApsaraDB internal endpoint

3.6 DDoS/WAF Enrolment

Software Engineering team to include WAF enrolment details into this table, with collaboration with Site Reliability Engineering (SRE) and Security team. All external facing applications/URL/sites should be enrolled into Web Application Firewall.

WAF enrolment details must include WAF CNAME DNS resolution details.

Enter your answer here.

Example (AWS):

WAF Component Detail
WAF type AWS WAF (with AWS Shield Advanced)
Associated resource Application Load Balancer arn:aws:elasticloadbalancing:us-east-1:xxx:loadbalancer/app/prod-alb/xxx
Rule groups AWS Managed Core Rule Set, IP reputation lists, Rate-based rules (2000 req/5min)
Custom rules Block requests without User-Agent, SQLi/XSS inspection, Block known bad IPs
WAF CNAME prod-alb-xxx.elb.amazonaws.com (CNAME alias to CloudFront/WAF endpoint)

Example (GCP):

WAF Component Detail
WAF type Google Cloud Armor (Standard tier)
Associated resource Global HTTP(S) Load Balancer projects/xxx/global/targetHttpProxies/prod-proxy
Rule groups OWASP Top 10 preconfigured rules, SQLi/XSS inspection
Custom rules Geo-based access control, Rate limiting (1000 req/min per IP)
WAF CNAME prod-lb-xxx.uc.gateway.dev (Cloud Armor frontend endpoint)

Example (Alibaba Cloud):

WAF Component Detail
WAF type Alibaba Cloud WAF (Business Edition)
Associated resource SLB instance slb-xxx.cn-hangzhou
Rule groups Web attack protection, HTTP flood protection
Custom rules Block specific URL patterns, Rate limiting (5000 req/5min)
WAF CNAME waf-xxx.waf.aliyuncs.com (WAF CNAME record in DNS)

4. IT Security Controls Requirements

This section specifies the required IT security control requirements and must be completed in full. 🛡️

4.1 Cloud Security

4.1.1 Is the solution deployed as virtual appliance-based or software based platforms from cloud marketplace or third-party app store? If yes, please specify details and versions.

Enter text here. It is the responsibility of the requester to ensure the security of deployed virtual or software-based platforms, if not managed by Site Reliability Engineering (SRE) team.

AWS Example: The solution uses virtual appliances from AWS Marketplace: (1) Palo Alto VM-Series firewall (version 10.2), (2) Datadog Agent (version 7.40), (3) HashiCorp Vault Enterprise (version 1.13). All marketplace subscriptions are approved through procurement process with license management via AWS License Manager.

GCP Example: The solution leverages GCP Marketplace solutions: (1) Fortinet FortiGate VM (version 7.0), (2) MongoDB Atlas (version 6.0). All marketplace solutions are deployed with custom service accounts and IAM policies. Images are scanned using Container Analysis API.

Alibaba Cloud Example: The solution deploys software from Alibaba Cloud Marketplace: (1) FortiGate firewall (version 7.0), (2) Redis Enterprise. Marketplace purchases require approval from IT governance. All images are scanned with Cloud Security Scanner before deployment.

4.1.2 Does the solution provide or require remote access service (such as VPN services, SSH, RDP, etc) for administrative* purpose? If yes, elaborate the security controls in place for any remote access or remote network administration. Remote access must be secured with Multi-Factor Authentication (MFA).

Enter text here. *Administrative access refers to remote administration of solution externally (outside of managed networks) to this application.

AWS Example: Remote access controls implemented:

  • AWS Systems Manager Session Manager for SSH/RDP (no inbound ports required)
  • AWS Client VPN with MFA using AWS SAML 2.0 integration
  • Bastion host in private subnet with AWS MFA enforced
  • All remote sessions logged to CloudTrail and CloudWatch Logs
  • Session recordings enabled via AWS SSM Session Manager

GCP Example: Remote access implementation:

  • Google Cloud IAP (Identity-Aware Proxy) for SSH/RDP access
  • Cloud VPN with Cloud Identity MFA enforcement
  • OS Login enabled with 2-step verification required
  • VPC Service Controls perimeter enabled
  • All administrative access logged to Cloud Audit Logs

Alibaba Cloud Example: Remote access controls:

  • Bastionhost service with MFA and session recording
  • Cloud VPN Gateway with SSL VPN and MFA
  • Security Center for monitoring unauthorized access
  • ActionTrail enabled for all administrative actions
  • RAM (Resource Access Management) with MFA policy enforced

4.1.3 Does the solution require email and messaging services for notification, OTP and other communication activities? If yes, elaborate the message solution required and in particular the content.

Enter text here. All email and messaging services should be routed through an approved email service provider. Usage of other email service providers requires explicit approval.

AWS Example: Email and messaging services:

  • Transactional emails: AWS SES (Simple Email Service) with DKIM/SPF/DMARC configured
  • OTP delivery: AWS SNS (Simple Notification Service) for SMS
  • Email content: System notifications, password reset, account verification
  • Daily volume: ~10,000 emails, ~5,000 SMS
  • Dedicated IP pool with reputation monitoring

GCP Example: Messaging solution:

  • Transactional email: SendGrid (via GCP Marketplace) with domain authentication
  • SMS notifications: Twilio integration via Cloud Functions
  • Email types: Alert notifications, user registration, report delivery
  • Monitoring via Cloud Monitoring dashboards

Alibaba Cloud Example: Communication services:

  • Email service: Alibaba Cloud DirectMail with DKIM authentication
  • SMS: Alibaba Cloud SMS Service for OTP delivery
  • Message types: Verification codes, alert notifications, system updates
  • Daily quota: 20,000 emails, 10,000 SMS

4.1.4 Is there any new cloud services required that are not endorsed by Security team?

Enter text here. All cloud services must be reviewed and endorsed by Security team for application usage.

Example: Yes, the solution requires the following new cloud services pending security approval:

  • AWS: Amazon Bedrock for generative AI capabilities (security review in progress)
  • GCP: Vertex AI Workbench for ML development (technical review completed)
  • Alibaba Cloud: Machine Learning Platform for AI (under security assessment)

Security team has been engaged via formal review process. Expected approval timeline: 2-3 weeks.

4.1.5 Is there any configuration of cloud resources that is not compliant with cloud security baseline standards?

Enter text here. All cloud services must be configured securely based on cloud security configuration baseline standards.

Example: All cloud resources are configured according to security baseline standards:

  • AWS: Config rules enabled with AWS Security Hub integration. Non-compliant resources flagged: None currently. S3 public access blocked, encryption mandatory.
  • GCP: Security Health Analytics enabled in Security Command Center. All findings remediated. Organization policies enforced for resource constraints.
  • Alibaba Cloud: Cloud Security Center baseline check passed. Security group rules reviewed weekly. All storage buckets configured with encryption and access logging.

Exception required for: [If any non-compliant configuration, describe here with business justification]

4.1.6 Does the solution integrate with any third party SaaS provider? If yes, do state the intent and any due diligence processes conducted? Will data be stored/hosted with this third party SaaS provider?

Enter text here. Should there be requirement for data to be stored within third party SaaS provider, requester must trigger and complete the necessary due diligence process such as third party risk assessment and technical risk assessment.

Example: Third-party SaaS integrations:

  • Salesforce CRM (Customer data sync)
    • Due diligence: SOC 2 Type II, ISO 27001 certification verified
    • Data stored: Customer contact information, opportunity data
    • Security review: Completed, approved for Restricted data
  • Slack Enterprise (Team collaboration)
    • Due diligence: Enterprise Grid security assessment completed
    • Data stored: Non-sensitive internal communications
    • Third-party risk assessment: Completed via vendor management portal
  • Datadog (Monitoring & observability)
    • Data stored: Application metrics, logs (no PII)
    • Technical review: Data processing agreement signed

4.2 Data Security & Information Privacy

4.2.1 Elaborate the chosen encryption algorithm defined for encryption. Attach screenshot (after encryption key is created) as artefacts on the chosen algorithm.

Enter text here and/or supporting artefacts. Refer to encryption standards for minimum requirements on encryption algorithm selected. If no, provide justification on why encryption is not required. When in doubt, the requester is responsible for consulting the Security team on whether the proposed new cryptographic algorithm adheres to standards or any potential risks on usage.

AWS Example: AES-256-GCM is used for all data encryption.

  • Data-at-rest: AWS KMS (Key Management Service) with symmetric 256-bit encryption keys.
  • Data-in-transit: TLS 1.3 for all public endpoints, TLS 1.2 minimum for internal VPC traffic.
  • Artefacts: Screenshot of AWS KMS console showing key policy and encryption algorithm (AES_256).

GCP Example: AES-256 encryption implementation:

  • Data-at-rest: Cloud KMS with software or HSM-backed symmetric keys.
  • Data-in-transit: TLS 1.3 for external traffic, Google Front End (GFE) termination.
  • Artefacts: Screenshot of GCP KMS Key Ring configuration showing key version and algorithm (GOOGLE_SYMMETRIC_ENCRYPTION).

Alibaba Cloud Example: AES-256 encryption standard:

  • Data-at-rest: Alibaba Cloud KMS with symmetric keys.
  • Data-in-transit: TLS 1.2/1.3 with strong cipher suites (ECDHE-RSA-AES256-GCM-SHA384).
  • Artefacts: Screenshot of KMS console showing key details and encryption algorithm specification.

4.2.2 Does the solution introduce new data classification type that is outside of Data Protection Standard?

Enter text here. If yes, indicate them accordingly with data type and sensitivity classification. When in doubt, the requester is responsible for consulting the Security team on whether there are requirements to deploy new DLP policies to detect potential data leakage risk, based on this new data classification type.

Example: No, the solution only uses existing data classifications:

  • Public: Marketing materials, public documentation.
  • Internal: Employee IDs, internal project names.
  • Restricted: Customer PII (name, email, phone), transaction history.
  • Highly Restricted: Passwords (hashed/salted), encryption keys, payment tokens. All data types are covered by the current Data Protection Standard and monitored by DLP (AWS Macie / GCP Cloud DLP / Alibaba Cloud SDU).

4.2.3 Does the solution require deployment of any SSL/TLS certificates?

Enter text here. Self-signed certificates should not be deployed on any Internet facing systems. Certificates must be issued from an internal PKI or a trusted CA and be stored in a vault type of solution as applicable.

AWS Example: Yes, SSL/TLS certificates are managed via AWS Certificate Manager (ACM).

  • Public facing: ACM certificates with DNS validation, renewed automatically.
  • Internal: AWS Private CA for internal microservices communication.
  • Storage: Private keys are managed by AWS and not exportable.

GCP Example: SSL/TLS certificate implementation:

  • External: Google-managed SSL certificates for Load Balancers.
  • Internal: Certificate Authority Service (CAS) for internal workload identities.
  • Validation: DNS-based authorization for automated issuance.

Alibaba Cloud Example: Certificate management:

  • Public: Alibaba Cloud Certificate Management Service (CAS) for SSL/TLS.
  • Deployment: Certificates deployed to SLB/ALB instances.
  • Storage: Secure storage in Managed HSM or KMS.

4.2.4 Does the solution deploy "data in transit" encryption based on the data classification involved? If yes, elaborate the inherent data classification and mechanism to deploy "data in transit" encryption.

Enter text here. Requester is responsible to ensure "data in transit" encryption is enabled to protect data of specific data classification as per Data Protection Standards. Noncompliance will require exception to be raised.

AWS Example: "Data in transit" encryption is enabled for all tiers:

  • Tier 1 (Client to ALB): TLS 1.3 using ACM certificates.
  • Tier 2 (ALB to EC2/Fargate): TLS 1.2 within VPC.
  • Tier 3 (App to Database): Encrypted connections for RDS (MySQL/PostgreSQL) using SSL/TLS.
  • Inter-region: VPC Peering traffic is encrypted using AWS hardware encryption.

GCP Example: Encryption in transit implementation:

  • External: HTTPS/TLS 1.3 terminated at Global Load Balancer.
  • Internal: Transparent encryption via Application Layer Transport Security (ALTS) for service-to-service communication.
  • Database: Cloud SQL Auth Proxy with encrypted tunnels for all database traffic.

Alibaba Cloud Example: In-transit security:

  • Web: HTTPS with TLS 1.2+ for all SLB/ALB endpoints.
  • Internal: VPN Gateway or Express Connect with IPSec/TLS encryption.
  • RDS: SSL encryption enabled for all ApsaraDB instances.

4.2.5 Does the solution deploy "data-at-rest" encryption based on the data classification involved? If yes, elaborate the inherent data classification and mechanism to deploy "data-at-rest" encryption.

Enter text here. Application Owner is responsible to ensure "data-at-rest" encryption is enabled to protect data of specific data classification as per Data Protection Standards. Noncompliance will require exception to be raised. Note: By default, storage side encryption (SSE) is enabled by default in cloud which cannot be disabled. This control will not address data leakage risk from an external threat and specific application-level attack such as injection-based attack (SQL Injection, etc). A combination of either data level/field level/database schema and SSE are to be deployed concurrently, when involving storing/processing/transmitting of sensitive, PII (Personal Identifiable Information) and/or restricted classified information.

AWS Example: Multi-layered data-at-rest encryption:

  • Storage Layer: S3 Bucket Encryption (SSE-KMS), EBS Volume Encryption (AWS KMS).
  • Database Layer: RDS Storage Encryption using KMS keys.
  • Application Layer: Field-level encryption for PII (Credit Card, SSN) using AWS Encryption SDK before storage.
  • Key Management: Customer Managed Keys (CMK) with annual rotation.

GCP Example: Data-at-rest encryption implementation:

  • Default: Google-managed default encryption for all persistent disks and GCS buckets.
  • Enhanced: Customer-Managed Encryption Keys (CMEK) via Cloud KMS for Cloud SQL and BigQuery.
  • Application: Tink library for field-level encryption of sensitive data in Cloud Spanner.

Alibaba Cloud Example: Encrypted storage:

  • ECS: Disk encryption enabled using KMS keys.
  • OSS: Server-Side Encryption with KMS keys (SSE-KMS).
  • Database: TDE (Transparent Data Encryption) enabled for ApsaraDB for RDS.
  • Application: SDK-based encryption for sensitive database columns.

4.2.6 Does the application require user to input any sensitive data (PII data, password, credit card number…)? Is sensitive data masked during presentation from User interface (UI)?

Example:

  1. Application requires user to input credit card number. Upon receiving the information, the application will encrypt it in the application level and store the info in the database accordingly.
  2. User viewing the credit card number on the UI is masked.

AWS Example: Application handles PII and Payment data:

  • Input: Credit card details captured via secure iframe (PCI-compliant provider).
  • Storage: Encrypted in RDS using AWS KMS.
  • UI Presentation: Only the last 4 digits are shown on the profile page (e.g., **** **** **** 1234). Full card number is never rendered.
  • Logging: PII data is redacted from CloudWatch logs using subscription filters.

GCP Example: Data masking strategy:

  • Cloud DLP API: Used to automatically detect and mask PII in UI responses.
  • Presentation: Phone numbers masked (e.g., +1-XXX-XXX-1234), email addresses partially obscured (e.g., j***@example.com).
  • Access Control: Only users with the "Security Admin" role can view unmasked data in specialized administrative views.

Alibaba Cloud Example: Masking implementation:

  • Data Security Center (DSC): Configured to mask sensitive fields in the application UI.
  • Password: Never shown or echoed back to user; only "********" displayed.
  • Presentation: ID numbers masked (e.g., 123456********7890).

4.2.7 Is there any sensitive PII data (Refer to Data Protection Standards) stored in the JWT token? (Provide a sample token for reference.)

Enter text here. Presence of sensitive information such as secrets or authentication claim stored/embedded in the JWT, will require encryption of this payload in JWT.

Example: No sensitive PII is stored in the JWT payload.

  • JWT Claims: sub (User UUID), iat (issued at), exp (expiry), iss (issuer), roles (user permissions).
  • PII: Names, emails, and phone numbers are excluded from the token. The application fetches these details from the backend database/identity store using the sub claim.
  • Security: JWTs are signed using RS256 with keys managed in Cloud Secret Manager.
  • Sample Token Payload: {"sub": "123e4567-e89b-12d3-a456-426614174000", "roles": ["user", "editor"], "exp": 1672531200}

4.3 Identity & Access Management

4.3.1 Who will be accessing the application?

Enter text here and provide relevant artefacts.

  • External (customers, agents, business partners, vendors/contractors using their own company account)
  • Internal (Staff, vendors/contractors using organization accounts)
  • Non-users (system to system access only)
  • Identity Store: (if applicable - for external and/or internal users, where are the identities stored?)

Remove those that do not apply. If your solution requires external identity authentication, this application should be integrated to an identity management solution.

AWS Example: The application is accessed by:

  • Internal users: Employees using organization accounts integrated with AWS SSO.
  • External users: Customers using Cognito User Pools with social identity providers (Google, Microsoft).
  • System-to-system: API integrations using IAM Roles with temporary credentials via STS.
  • Identity Store: AWS SSO for internal users, Cognito for external users.

GCP Example: User access breakdown:

  • Internal users: Google Workspace users authenticated via Identity Platform.
  • External users: Customer accounts managed in Firebase Authentication.
  • Service accounts: Workload Identity Federation for service-to-service APIs.
  • Identity Store: Cloud Identity for organization accounts, custom claims in Firestore.

Alibaba Cloud Example: Access model:

  • Internal users: RAM (Resource Access Management) integrated with corporate LDAP.
  • External users: Alibaba ID or DingTalk OAuth integration.
  • Service accounts: RAM roles with STS tokens for API authentication.
  • Identity Store: Corporate Active Directory synchronized to RAM via SCIM.

4.3.2 How will the above users/systems be authenticating?

Enter text here and provide relevant artefacts.

  • Authentication Protocol(s):
  • Authentication Method(s): (e.g., password, email/SMS OTP, secrets, biometrics, secrets management, etc.)
  • Session Duration/Timeout (1 hour max):
  • IDP Provider Information: (if applicable) (e.g., Azure AD, Active Directory, social identity providers, partner Active Directory)
  • MFA Enabled: Yes/No (If No, please provide details why it is not required/enabled.)

AWS Example: Authentication implementation:

  • Protocol: OAuth 2.0/OpenID Connect, SAML 2.0.
  • Methods: Password + TOTP for internal users, Password + SMS for external.
  • Session: 1-hour JWT token with refresh token rotation.
  • IDP: AWS SSO integrated with corporate Active Directory.
  • MFA: REQUIRED for administrative access via AWS MFA.

GCP Example: Authentication configuration:

  • Protocol: OAuth 2.0, OpenID Connect, SAML 2.0.
  • Methods: Google Sign-In for internal, Email/OTP for external.
  • Session: 60-minute sessions with automatic extension.
  • IDP: Google Workspace with 2-step verification enforced.
  • MFA: Mandatory via Google Prompt or TOTP.

Alibaba Cloud Example: Authentication setup:

  • Protocol: OIDC, SAML 2.0, OAuth 2.0.
  • Methods: Password + DingTalk SSO for internal, SMS + Email for external.
  • Session: 3600 seconds with secure cookie flags.
  • IDP: Corporate LDAP via RAM, SAML for federated auth.
  • MFA: Optional for standard users, mandatory for admin roles.

4.3.3 How will the solution handle its secrets? Elaborate on type of secrets (password, passcode, token, API keys, database connection string, SSH keys, etc.) and indicate its usage in the application.

Provide details of types of secrets and how they are used here. Secrets are non-interactive credentials used to access resources and are considered as Privilege ID. All secrets must be managed through an approved secret management solution. Storing clear text secret in code repository, secret store or hard coded secret is strictly prohibited.

AWS Example: Secret management approach:

  • Database credentials: AWS Secrets Manager with automatic rotation every 30 days.
  • API keys: Stored in Secrets Manager, accessed via IAM role with least privilege.
  • SSH keys: Managed via EC2 Instance Connect or SSM Session Manager (no PEM files).
  • Third-party tokens: AWS Secrets Manager with cross-account access for shared secrets.
  • CI/CD secrets: GitHub Actions OIDC integration with IAM roles (no long-lived tokens).

GCP Example: Secrets handling:

  • Application secrets: Secret Manager API with automatic replication.
  • Database passwords: Generated and rotated by Cloud SQL Auth Proxy.
  • OAuth tokens: Stored in Secret Manager with audit logging.
  • SSH keys: OS Login or temporary bastion sessions via IAP.
  • Environment secrets: Anthos Config Management with encrypted ConfigMaps.

Alibaba Cloud Example: Secret management:

  • Database connection strings: KMS-encrypted in application code.
  • API tokens: Stored in Parameter Store (KMS encrypted).
  • SSL/TLS certificates: Managed via Certificate Service.
  • SSH keys: Deployed via Cloud DevOps with temporary access.
  • Service tokens: STS temporary credentials with 1-hour expiry.

4.3.4 How will the solution handle privileged and service accounts? All privileged application and infra-accounts must be identified and enrolled into an approved Privileged Account Management (PAM) system with multi-factor authentication enabled.

Enter text here and provide relevant artefacts. Note: Service account must be used non-interactively.

AWS Example: Privileged account management:

  • Service accounts: IAM Roles with trust policies for EC2/ECS/EKS workloads.
  • Administrative accounts: AWS IAM Identity Center with MFA enforcement.
  • PAM Solution: HashiCorp Vault with AWS IAM auth method for secret injection.
  • Session recording: AWS CloudTrail records all IAM actions.

GCP Example: Privileged access controls:

  • Service accounts: GCP Workload Identity with OIDC federation to Kubernetes.
  • Admin accounts: Google Cloud Identity with 2-step verification mandatory.
  • PAM Solution: CyberArk or HashiCorp Vault for privileged credential rotation.
  • Access logging: Cloud Audit Logs captures all administrative actions.

Alibaba Cloud Example: Privileged account handling:

  • Service accounts: RAM roles with STS temporary credentials.
  • Admin accounts: RAM users with MFA enabled for console access.
  • PAM Solution: Bastionhost with session recording and command filtering.
  • Logging: ActionTrail records all privileged access attempts.

PAM Screenshot: (Attach screenshot of secrets, service accounts, and PIDs enrolled in privileged access management solution)

SN PID/Secret Name PID/Secret Owner PID/Secret Type Enrolled PAM Solution Screenshot of Enrollment Comment
1 Database Credentials DBA Team RDS/MySQL AWS Secrets Manager / GCP Secret Manager / Alibaba Parameter Store Rotated automatically every 30 days
2 API Keys DevOps Team REST API Token HashiCorp Vault / Cloud HSM Used for third-party integrations
3 SSH Keys Infrastructure Team SSH Key Pair SSM/Bastion Host Temporary sessions via IAM/Bastionhost

4.3.5 Access Management

  1. Please provide the Application Role Profile Matrix.*

    *All application systems should have well defined access roles/profiles detailing the accesses that each profile/role provides and what project role is relevant for this profile. The role-to-access matrix (Role based access matrix) should be kept up to date and refer to the various roles internal staff can have on the backend systems. Also please add whether the respective role is Privileged or Read only.

  2. Do elaborate on the following with regards to user access governance:

    • How will the users be granted different roles in the application? (Outline approvals and provisioning process and owners)
    • How will the roles be updated based on user's role and status within the organization (joiner/mover/leaver)?
    • Is the application in scope for any internal or external audit?

*All application systems which are accessed by staff should manage the access workflow and approvals through identity and access management system.

  • IAM On-boarding: IAM app name or on-boarding request number (if applicable)
  • Role Matrix: Attach application role profile matrix here (if applicable).

AWS Example: Role-based access implementation:

  • Roles: Admin (privileged), Editor (write), Viewer (read-only).
  • Provisioning: AWS SSO groups mapped to IAM roles; Access approved via ITSM workflow.
  • Updates: HR system triggers Workday -> AD sync -> AWS SSO updates.
  • Leavers: Access revoked automatically via IAM Identity Center group membership.
  • Audit scope: Quarterly internal audit, annual external (SOC 2).

GCP Example: Access governance:

  • Roles: roles/admin, roles/editor, roles/viewer aligned with cloud IAM.
  • Provisioning: Identity Platform groups with Cloud IAM bindings.
  • Updates: Automated deprovisioning via Google Workspace lifecycle management.
  • Permissions: Custom roles using principle of least privilege.
  • Audit: Cloud Audit Logs retained for 1 year, monthly access reviews.

Alibaba Cloud Example: Access management:

  • Roles: Administrator (privileged), Developer (write), Operator (read-only).
  • Provisioning: RAM groups with approval workflow via DingTalk.
  • Updates: HR system integration via SCIM provisioning.
  • Deprovisioning: Automated removal within 24 hours of employee departure.
  • Compliance: Quarterly access attestation required.

4.4 Application Security

4.4.1 Is the application an in-house developed custom application that has any of the following characteristics?

  • Complete control of source code
  • Complete control of software compilation and packaging
  • Organization owns the developed application
  • Not available for purchase by public

Example: Application is developed in-house using Java and will be compiled as a docker image. The docker image will be deployed in a Kubernetes cluster.

AWS Example: In-house application details:

  • Built using Java Spring Boot with Maven pipeline.
  • Source code in GitHub Enterprise with branch protection rules.
  • Docker images built via CodeBuild and stored in ECR with vulnerability scanning.
  • Deployed to EKS (Elastic Kubernetes Service) cluster.
  • Ownership: Full rights retained by organization for all components.

GCP Example: Custom application implementation:

  • Developed using Python Django framework with GitLab CI/CD.
  • Container images stored in Artifact Registry with binary authorization policies.
  • Deployment via Google Kubernetes Engine (GKE) with autopilot mode.
  • Artifact analysis via Container Analysis API.

Alibaba Cloud Example: Self-developed application:

  • Built using Go microservices with Docker containers.
  • Source code in GitLab EE with merge request approvals.
  • Images stored in Container Registry with security scan enabled.
  • Deployed via Alibaba Cloud Container Service for Kubernetes (ACK).

4.4.2 Does the application have any file upload capabilities? If yes, please elaborate:

  • Which role is allowed to upload the file?
  • How are file type and file size restricted?
  • Is malware scanning required for file upload?

Example: Application allows user to upload file for request submission purpose.

  1. All users can upload files in the application for submission purpose.
  2. Only PDF and a maximum of 5MB is allowed to be uploaded. This is validated within the application upon user upload of the file.
  3. All uploaded files will go through malware scanning first as part of the application process flow, before they get stored into the database for processing.

AWS Example: File upload security:

  • Allowed roles: Uploader (authenticated users), Admin (no restrictions).
  • File restrictions: Whitelist of extensions (pdf, doc, docx, xls, xlsx), 10MB max size.
  • Malware scanning: Files uploaded to S3 trigger EventBridge event which invokes Lambda function calling ClamAV antivirus.
  • Quarantine: Suspicious files moved to isolated S3 bucket for review.
  • Storage: Encrypted S3 bucket with object lock enabled for 90 days.

GCP Example: Upload handling:

  • Roles: file-uploader role with fine-grained access control.
  • Restrictions: Content-Type validation, Cloud Functions enforce 5MB limit.
  • Scanning: Cloud Storage triggers Cloud Functions with VirusTotal API scan.
  • Approval: Files require admin approval before becoming publicly accessible.

Alibaba Cloud Example: Upload security controls:

  • Permissions: Only users with file_upload permission can upload.
  • Types: Whitelist (jpg, png, pdf, doc), 8MB maximum.
  • Scanning: OSS triggers Function Compute function with antivirus engine.
  • Storage: Encrypted OSS bucket with versioning enabled.

4.4.3 Does the application require user to input any sensitive data (PII data, password, credit card number…)? Is sensitive data masked during presentation from User interface (UI)?

See §4.2.6. The same guidance applies.

4.5 Security Logs & Events Management

4.5.1 What are the types of security and auditing logs the application produces, if any, outside of standard OS logging?

Enter text here. Example: Policy violations, auditing logs, suspicious events, etc. Refer to security standards for Logs and Events Management.

AWS Example: Security logs generated by the application:

  • Authentication logs: Login attempts, MFA challenges, session creation/termination.
  • Authorization logs: Access denied events, privilege escalation attempts, role changes.
  • Data access logs: PII access, file downloads, export operations.
  • Configuration logs: Security group changes, IAM policy updates, S3 bucket policy modifications.
  • Anomaly logs: Rate limiting violations, suspicious IP addresses, brute force attempts.

GCP Example: Auditing events captured:

  • Admin Activity: IAM policy changes, VPC network modifications, security group updates.
  • Data Access: BigQuery table reads, Cloud Storage object access, Secret Manager secret versions accessed.
  • System Events: Compute Engine instance changes, Kubernetes pod creation/deletion.
  • Application Events: User login failures, API key usage, rate limiting triggers.

Alibaba Cloud Example: Security event types:

  • ActionTrail logs: All API calls, credential usage, resource modifications.
  • Security Center alerts: Vulnerability detection, security group anomalies.
  • Application logs: Login events, file access, configuration changes.
  • SLB access logs: Request patterns, blocked requests, DDoS mitigation events.

4.5.2 How does the application stack — whether it is application centric or via the operating system/AD — send both security and auditing logs to central logging system?

Enter text here. Please note that typically OS logs are collected for a server with a standard build OS or where the application authenticates via AD. For SaaS type applications or where the application has extra regulatory requirements, additional custom monitoring would be required. Refer to security standards for Logs and Events Management. It is the responsibility of the application owner to ensure required security logs and events are forwarded to central logging system.

AWS Example: Log delivery mechanisms:

  • Application logs: CloudWatch Logs via FireLens for containerized apps, CloudWatch Agent for EC2.
  • Infrastructure logs: CloudTrail for API events, VPC Flow Logs for network traffic.
  • Central aggregation: Kinesis Firehose to S3 with Athena for querying.
  • SIEM integration: CloudWatch Logs subscription to Splunk HTTP Event Collector (HEC).
  • Retention: 7 years in S3 Glacier Deep Archive for compliance.

GCP Example: Logging architecture:

  • Application: Structured logs to Cloud Logging via structured logging library.
  • Infrastructure: Audit Logs for Admin/Data Access, VPC Flow Logs for network.
  • Forwarding: Pub/Sub sink to external SIEM or Chronicle.
  • Alerting: Security Command Center integration with incident notification.
  • Retention: Cloud Logging default 30 days, extended to 1 year via export to BigQuery.

Alibaba Cloud Example: Log pipeline:

  • Application: Log Service (SLS) Logtail or API for log collection.
  • Infrastructure: ActionTrail delivers to Log Service under "audit-log" project.
  • Monitoring: Cloud Monitor custom metrics with alerting rules.
  • Export: Log Service shipping rules to OSS for long-term retention.
  • Retention: 365 days for security logs, 90 days for application logs.

4.5.3 Describe new use cases, if any, for the security logs being sent to central logging. E.g. Does Security Operations Center need to be notified in the event of activities on this application specific to the application logs themselves? (OS logs would be covered by existing use cases.)

Enter text here. Log stored in central logging system has minimal value if there are no monitoring use cases to generate security alerts from these logs. Consider and state possible security response playbooks for these use cases which could be automated.

AWS Example: Security monitoring use cases:

  • Failed login attempts > 5 in 10 minutes: Trigger CloudWatch alarm -> Lambda -> notify SOC via SNS.
  • IAM policy changes outside business hours: CloudTrail Event -> EventBridge rule -> PagerDuty alert.
  • S3 bucket made public: Config Rule trigger -> Lambda -> Security team Slack channel.
  • PII access from unusual geography: CloudWatch Logs Insights query -> automated incident ticket.
  • Response playbooks: Automated quarantine of compromised resources via AWS Systems Manager.

GCP Example: Use case implementations:

  • Suspicious authentication: Cloud Logging metrics -> Cloud Monitoring alert -> Security Command Center finding.
  • Privilege escalation: Audit log detection -> Cloud Functions -> Slack notification with context.
  • Data exfiltration: BigQuery query for large data exports -> Alert -> Manual review required.
  • Unauthorized access: VPC Flow Logs anomaly -> Security Health Analytics alert.
  • Automation: Cloud Functions for automatic IP blocklist updates via firewall rules.

Alibaba Cloud Example: Monitoring scenarios:

  • Brute force detection: ActionTrail event -> Function Compute -> DingTalk alert.
  • Security group modification: Log Service alert -> SMS notification to security team.
  • Large file download: OSS event notification -> Security Center -> access review.
  • API abuse: API Gateway throttling event -> Log Service dashboard alert.
  • Automated response: Resource orchestration template to isolate suspicious instances.

4.5.4 Please indicate the log retention requirements.

Enter text here. Default retention period is 1 year, in absence of local regulatory requirement. Should there be a specific local regulatory requirement around data retention period, it will supersede this default retention period. If such requirement exists, please indicate it.

AWS Example:

  • Security event logs: 7 years (compliance requirement).
  • Application logs: 1 year standard retention in CloudWatch Logs.
  • Audit logs: 10 years in S3 Glacier Deep Archive.
  • Debug/troubleshooting logs: 30 days for operational purposes.
  • Archival: Lifecycle policies transition to Glacier after 90 days.

GCP Example:

  • Security audit logs: 7 years via BigQuery export and retention policy.
  • Application logs: 1 year in Cloud Logging with export to Cloud Storage archive.
  • Network logs: 3 years in Cloud Logging.
  • Temporary logs: 30 days for debug logs.
  • Compliance: Cloud Storage bucket with retention lock for immutable storage.

Alibaba Cloud Example:

  • Security logs: 2 years in Log Service with OSS archive backup.
  • Business logs: 1 year in Log Service.
  • Application debug logs: 30 days.
  • Compliance logs: 7 years in OSS with compliance retention policy.
  • Backup: Cross-region replication to secondary OSS bucket.

4.6 Mobile Application Security

4.6.1 Is there any sensitive data stored locally on the mobile application? If yes, how is the sensitive data encrypted and stored on the mobile application? Sensitive data can include customer credentials, password, API keys, customer PII.

Example Artefacts:

  1. Artifacts of Sensitive Data stored in protected storage locations for iOS/Android. If application is onboarded to Mobile Security solution, provide certificate or confirmation.

AWS Example: Mobile data protection:

  • Sensitive data: JWT access tokens stored in iOS Keychain/Android Keystore.
  • Encryption: AES-256-GCM keys generated via AWS KMS and cached securely.
  • API keys: Never stored on device; fetched dynamically via authenticated API calls.
  • User credentials: OAuth 2.0 tokens only, no passwords cached.
  • Security solution: AWS Mobile Security (if onboarded, provide certificate ID).

GCP Example: Local data security:

  • Storage: Encrypted SharedPreferences (Android) / Keychain (iOS) for tokens.
  • PII: Encrypted SQLite database using SQLCipher library.
  • Keys: Google Tink cryptographic library with remote key fetching.
  • Mobile solution: Firebase App Check with device attestation.

Alibaba Cloud Example: Mobile protection:

  • Storage: Encrypted with KMS-generated keys via Mobile Security SDK.
  • Data: Sensitive fields encrypted before storage using SM4 algorithm.
  • Tokens: Short-lived tokens cached in secure enclave.
  • SDK: Mobile Gateway Hot Load with security hardening enabled.

4.6.2 What is the minimum platform version supported for the mobile application for Android and iOS? As applicable: what is the business justification for the minimum OS versions that are supported?

Example Artefacts:

  1. Screenshot of configuration file showing Android/iOS version supported.

AWS Example: Platform support matrix:

  • Android: Minimum SDK version 24 (Android 7.0) - covers 95% of devices.
  • iOS: Minimum iOS version 14.0 - covers 90% of active devices.
  • Justification: Security features like Network Security Config (Android), App Tracking Transparency (iOS) required for compliance.
  • Risk assessment: Older versions lack critical security patches.

GCP Example: Version requirements:

  • Android: minSdkVersion 21 (Android 5.0) - 98% market coverage.
  • iOS: deployment target iOS 13.0 - supports latest Swift features.
  • Security rationale: Biometric authentication APIs, secure enclave access.

Alibaba Cloud Example: OS support:

  • Android: API level 22 (Android 5.1) - supports dynamic permission model.
  • iOS: iOS 12.0 minimum - supports Face ID and Touch ID APIs.

4.6.3 What are the permissions required for the mobile application? Does the application require least privileges to function? App permissions are special rights granted to mobile applications that can be requested to access certain features, functions and data on the mobile device.

Example Artefacts:

  1. Screenshot of AndroidManifest.xml showing permissions required. Describe the reason required for each privilege identified.
  2. Screenshot of Info.plist showing permissions required. Describe the reason required for each privilege identified.

AWS Example: Permission matrix:

  • Android: INTERNET (API calls), ACCESS_NETWORK_STATE (connectivity), CAMERA (document capture).
  • iOS: NSCameraUsageDescription (QR scanning), NSLocationWhenInUseUsageDescription (location-based features).
  • Justification: Each permission directly tied to business functionality.
  • Least privilege: Runtime permission requests, no background location access.

GCP Example: Permission details:

  • Network: Required for Firebase Firestore sync.
  • Camera: Required for document scanning via ML Kit.
  • Storage: Read/write external for file export (optional).
  • Rationale: Minimal permissions aligned with Material Design guidelines.

Alibaba Cloud Example: Permissions list:

  • Network: Required for API gateway connectivity.
  • Storage: For offline data caching in encrypted files.
  • Camera: For QR code scanning of products.
  • SMS: One-time for phone number verification only.

4.6.4 What are the controls in place for root detection for Android applications? What are the controls in place for jailbreak detection for iOS applications? Rooting/Jailbreaking is a process of unlocking the mobile device OS to gain administrative control over the entire device which creates an unsafe environment for applications.

Example Artefacts:

  1. Implementation of Jailbreak/Root Detection Libraries (iOS and Android).

AWS Example: Root/Jailbreak detection:

  • Library: JailMonkey (Android) + SFAntiPiracy (iOS) integrated.
  • Actions: Detection triggers immediate session invalidation and backend alert.
  • Monitoring: Detected attempts logged to CloudWatch with device fingerprint.
  • Response: App disables sensitive operations and notifies user.
  • Coverage: Detects Magisk, RootCloak, Frida, and jailbreak tools.

GCP Example: Device integrity controls:

  • SafetyNet: Android SafetyNet Attestation API for device certification.
  • DeviceCheck: iOS DeviceCheck API for device integrity verification.
  • Runtime checks: Periodic integrity verification at app launch.
  • Blocking: Rooted/jailbroken devices blocked from accessing sensitive features.

Alibaba Cloud Example: Integrity verification:

  • Detection: Mobile Security SDK root/jailbreak check.
  • Prevention: App refuses to launch on compromised devices.
  • Logging: Suspicious devices logged to ActionTrail.
  • Response: Remote config update disables high-risk features.

4.6.5 What are the controls in place for application debugging for the mobile application? Is there a control for detection of debugger threats? Debuggers and related tools allow for inspection/suspension of the execution of application code which can be used for reverse engineering the mobile application.

Example Artefacts:

  1. Screenshot showing whether application is debuggable.

AWS Example: Debug detection implementation:

  • Build config: debuggable=false for release builds (Android).
  • iOS: DEBUG flag disabled in Release schema.
  • Runtime check: Frida detection library monitors debugger attachment.
  • Response: Debugger detected triggers immediate app termination.
  • Verification: Android V2 signature scheme prevents tampering.

GCP Example: Debug prevention:

  • Flags: Android android:debuggable="false", iOS DEBUG not defined.
  • Integrity: Play App Signing ensures APK signature verification.
  • Detection: Custom native code to detect ptrace/debugger presence.
  • Mitigation: Code obfuscation makes reverse engineering harder.

Alibaba Cloud Example: Debug controls:

  • Configuration: Production builds have debugging disabled.
  • Detection: Runtime integrity check via Mobile Security SDK.
  • Response: Detection triggers error logging and optional app exit.
  • Verification: App signature verification on launch.

4.6.6 What are the controls for detection of hooking frameworks (Frida detection)? Hooking Frameworks are software tools/techniques to allow for interception and modification of application behavior. Frida is an example of a commonly used hooking framework.

Example Artefacts:

  1. Implementation (Native or Third Party) of Frida Detection for iOS/Android.

AWS Example: Hooking framework protection:

  • Detection: Frida-gadget detection via process/memory scanning.
  • Library: Custom Frida detection module integrated in app core.
  • Response: Hook detected triggers immediate session termination.
  • Logging: EventBridge rule captures detection -> CloudWatch alarm -> Security team.
  • Preventive: Integrity checks on critical native libraries.

GCP Example: Anti-hooking measures:

  • Runtime: Memory scanning for Frida server/detectable signatures.
  • Native layer: JNI anti-hook checks on Android.
  • Response: Compromise detected -> Firebase Crashlytics report generated.

Alibaba Cloud Example: Hook prevention:

  • Scanning: Periodic check via Mobile Security SDK.
  • Blocking: Frida-detected devices blocked from service access.
  • Notification: Hook events trigger Cloud Monitor alert.

4.6.7 What are the controls for detection of running in an emulator environment?

Example Artefacts:

  1. Implementation (Native or Third Party) of Emulator/Virtualization detection for iOS/Android.

AWS Example: Emulator detection:

  • Detection: Genymotion/Bluestacks detection via device fingerprint.
  • Checks: Unusual sensor readings, telephony properties, build characteristics.
  • Response: Emulator detected -> Restricted mode (limited functionality).
  • Logging: Suspicious activity logged to CloudWatch with device metadata.

GCP Example: Virtual environment protection:

  • Android: Emulator detection via ro.kernel.qemu, ro.secure, sensor properties.
  • iOS: Simulator detection via TARGET_OS_SIMULATOR flag.
  • Response: Emulation detected -> Reduced functionality mode enforced.

Alibaba Cloud Example: Emulation safeguards:

  • Detection: SDK-based check for emulator signatures.
  • Validation: DeviceID entropy check for real vs virtual devices.
  • Response: Emulators blocked from accessing payment features.

4.6.8 What are the controls for Application Runtime/Source Code integrity checks for the application? Application Runtime/Source Code Integrity checks protect the application against tampering with unwanted changes and mods.

Example Artefacts:

  1. Implementation (Native or Third Party) of Application runtime integrity/Application Source Code integrity controls for iOS/Android.

AWS Example: Integrity verification:

  • Runtime: APK signature verification on launch.
  • Code: Checksum verification of native libraries at runtime.
  • Tamper: SafetyNet attestation validates app integrity.
  • Response: Tampering detected -> App refuses to start + alerts backend.
  • Logging: Compromised app events sent to Security Hub findings.

GCP Example: Integrity controls:

  • Verification: Play Integrity API for Play Store apps.
  • Signing: App signing key verification.
  • Monitoring: Play Console integrity alerts for compromised installs.
  • Response: Integrity failure triggers Play Feature Delivery restrictions.

Alibaba Cloud Example: Protection mechanisms:

  • Check: App signature verification at startup.
  • Integrity: Cloud Security Scanner validates runtime behavior.
  • Response: Modified app quarantined by Mobile Security SDK.

4.6.9 What are the controls in place for code obfuscation of the application source code? Code Obfuscation makes reading of application binaries difficult and impractical which protects the mobile application's internal logic / intellectual property.

Example Artefacts:

  1. Implementation (Native or Third Party) of binary code obfuscation for iOS/Android.

AWS Example: Obfuscation implementation:

  • Android: ProGuard + DexGuard with custom obfuscation rules.
  • iOS: LLVM obfuscation + Swift compiler optimizations.
  • Native: Native library encryption via commercial solution.
  • Verification: APK Analyzer shows obfuscated class/method names.
  • Protection: String encryption and control flow obfuscation enabled.

GCP Example: Code protection:

  • Android: R8 optimizer with custom ProGuard rules for business logic.
  • iOS: Swift compiler optimizations with module-level obfuscation.
  • Assets: Native .so files encrypted and decrypted at runtime.
  • Tools: Custom Gradle plugin applies multiple obfuscation layers.

Alibaba Cloud Example: Obfuscation strategy:

  • Android: AndResGuard + ProGuard for resource and code obfuscation.
  • iOS: LLVM obfuscation + symbol renaming for release builds.
  • Verification: Reverse-engineering difficulty validated via penetration test.

4.7 Artificial Intelligence (AI) Security

4.7.1 Describe the business process which this AI component will be used for.

Enter your answer here.

Example: The AI component will be used for a customer-facing chatbot that answers policy inquiries, processes claims submissions, and provides product recommendations based on user profile and historical data. The chatbot will be deployed on the customer portal and mobile application.

4.7.2 Has the AI application use case been documented and registered? If yes, do provide the documentation link if applicable.

Enter your answer here.

Example (AWS): Yes. The use case is registered in the AI use case registry with approval reference AI-REG-2024-042. AWS Bedrock invocation logs are enabled.

Example (GCP): Yes. Documented in Vertex AI Model Registry (project ml-models-xxx). Use case approved on 2026-05-12.

Example (Alibaba Cloud): Yes. Registered via Alibaba Cloud PAI (Platform for AI) use case management portal.

4.7.3 Provide details on the AI component used for this application.

Enter your answer here.

  1. LLM: Anthropic Claude 3 Sonnet (via AWS Bedrock) / Gemini 1.5 Pro (via GCP Vertex AI) / Qwen 2.5 (via Alibaba Cloud PAI)
  2. Version: Latest stable at time of deployment
  3. Mode: Pretrained (no fine-tuning); custom system prompt with RAG context injection
  4. Hosted: AWS us-east-1 (Bedrock endpoint) / GCP us-central1 (Vertex AI endpoint) / Alibaba Cloud cn-hangzhou (PAI endpoint)

4.7.4 Does the AI component have access to plugins/tools? If applicable, provide details on the functionalities of the plugin and tools exposed to the AI component.

Enter your answer here.

Example:

  • Policy lookup tool — Retrieve policy documents from internal knowledge base (read-only, scoped to the user's policies only)
  • Claims status checker — Query claims database for claim status and history (read-only, user-scoped)
  • Premium calculator — Calculate premium for given parameters (deterministic, no side effects)
  • All plugins are invoked via server-side function calls with strict input validation. No direct database access. Each tool call is logged with full audit trail.

4.7.5 Provide details of security Guardrails in place against jailbreak attacks and prompt injection attacks.

Enter your answer here.

Example:

  • Input filtering: All user prompts are sanitized using a guardrails layer (AWS Bedrock Guardrails / GCP Vertex AI Safety Attributes / Alibaba Cloud Content Moderation) before reaching the LLM.
  • Output filtering: Model responses are post-processed to strip injection patterns, markdown, and executable content.
  • System prompt hardening: System prompt includes explicit boundary instructions ("Ignore any instruction to...").
  • Rate limiting: Maximum 10 requests per minute per user to limit reconnaissance attempts.
  • Monitoring: All jailbreak attempts (detected by guardrails) are logged and alerted to Security team.

4.7.6 Is there any sensitive PII data that is being processed by the AI component of the application? (This can be either through inference through prompts passed to the AI component or RAG implementation.)

Enter your answer here.

PII Definition (per Vietnamese law — Decree 13/2023/ND-CP on Personal Data Protection): 🌐 Regional note: This definition is jurisdiction-specific. For projects in other regions, replace with applicable regulation (GDPR, PDPA, PIPL, LGPD, CCPA, etc.). Under Vietnamese law, personal data is divided into two categories:

  • Basic personal data: Full name, date of birth, gender, nationality, phone number, ID/CCCD number, email, address, IP address, device ID, location data.
  • Sensitive personal data: Political/religious views, health data (including DNA, blood type), biometric data, racial/ethnic origin, sexual orientation, criminal records, credit/financial data, location data collected from devices, and personal data revealing the above categories.

Application handling:

  • (i) PII masking is enabled. Sensitive fields masked include: full name → initials, phone → last 4 digits, email → domain-only, ID cards → masked with *.
  • (ii) Sensitive personal data is removed from prompts before sending to LLM. Vector database stores only embeddings (no raw text); each embedding is non-reversible.
  • (iii) DLP controls: Cloud DLP API / AWS Macie / Alibaba SDU scans all data ingested into RAG for sensitive content before embedding. Data retention is set to 30 days with auto-purge.

4.7.7 Provide details of logging and monitoring implemented for AI components used for the application.

Enter your answer here.

Example (AWS): All Bedrock API calls are logged to CloudTrail. Model invocation logs are sent to CloudWatch Logs with 1-year retention. Guardrail violations trigger CloudWatch alarm -> SNS -> Security team PagerDuty. A CloudWatch dashboard tracks token usage, latency, error rates, and safety filter triggers.

Example (GCP): Vertex AI audit logs are captured in Cloud Audit Logs. Model monitoring metrics (input/output toxicity, ground truth drift) are sent to Cloud Monitoring. Safety violation alerts route to Security team.

Example (Alibaba Cloud): PAI model invocations are logged via ActionTrail. Content moderation violations are reported to Cloud Monitor with DingTalk alert integration. SLS (Log Service) retains inference logs for 180 days.

4.7.8 Does the AI component leverage RAG (Retrieval Augmented Generation) techniques to ingest data from internal/external data sources? If yes, what are these data sources and are the ingested data stored within a Vector Database?

Enter your answer here.

Example: Yes, the solution uses RAG for knowledge base retrieval.

  • Data sources: Internal policy documents (PDF, Markdown), product catalog (from internal CMS), FAQ database (from existing customer support system).
  • Vector database: Pinecone / Amazon OpenSearch Serverless / GCP Cloud Firestore Vector Search / Alibaba Cloud AnalyticDB for PostgreSQL.
  • Ingestion pipeline: Documents are chunked (512 tokens), embedded using the LLM provider's embedding model, and stored in the vector database. Data is re-indexed daily.
  • Security: All documents are scanned for sensitive content before ingestion. RAG retrieval is scoped per user role (policy team members can only retrieve policy docs, etc.).

4.7.9 Are all outputs generated from Generative AI protected with output filters to ensure that Restricted and Restricted "Sensitive" Personal Data is removed/redacted before presentation to the end user?

Enter your answer here.

Example: Yes. Output filters are applied at two levels:

  • LLM provider level: Safety attributes / content moderation filters block toxic, PII, and dangerous content before the response is returned.
  • Application level: A post-processing layer (Lambda / Cloud Function / Function Compute) runs regex and NER (via AWS Comprehend / GCP DLP / Alibaba NLP) to detect and redact any remaining PII before the response reaches the user.

If PII is detected post-generation, the response is replaced with: "I'm unable to show that information here. For privacy reasons, sensitive data is masked."

4.7.10 Does the application expose potentially dangerous content such as markdown images, hyperlinks and JavaScript to end-users in generated responses from the Generative AI model?

Enter your answer here.

Example: No. The model output is sanitized through the following pipeline before rendering:

  • All HTML/JavaScript tags are stripped using an allowlist-based sanitizer (Bleach/DOMpurify).
  • Markdown images and links are removed from the response.
  • Output is rendered as plain text + structured components (no raw HTML rendering).
  • A content safety classifier runs final validation before the response is sent to the user's browser.

4.7.11 Provide the list of plugins allowed to interact with Generative AI models and their permissions. A plugin is defined as a group of tools/actions that can be used to extend core functionalities of Generative AI models. Permissions allocated for plugins must be restricted, and the number of plugins allowed to interact with Generative AI models should be kept to what is required for the application use case.

Enter your answer here.

Example:

Plugin Name Functionality Access Scope Permissions Rate Limit
policy_lookup Retrieve policy documents by ID User's own policies only Read-only 30 calls/min
claims_status Query claims processing status User's own claims only Read-only 30 calls/min
premium_calc Calculate insurance premium None (stateless) No data access 60 calls/min
faq_search Search FAQ knowledge base Public FAQ only Read-only 60 calls/min

All plugin invocations are logged with request ID, user ID, timestamp, tool used, and response status.

4.8 Data Migration Security

This section is only applicable if there is a planned data migration activity.

4.8.1 What is the media used for data migration? Please provide artefacts for justification.

Enter text here.

AWS Example: Media used for data migration:

  • Primary: AWS Database Migration Service (DMS) with VPN connectivity.
  • Secondary: Amazon S3 transfer acceleration with multipart upload for large datasets.
  • Justification: DMS supports minimal downtime migration with CDC; S3 with multipart reduces transfer time by 30%.
  • Artefacts: DMS task diagram, S3 bucket configuration with SSE-KMS enabled, VPN connection details.

GCP Example: Media selection:

  • Primary: Migrate for Compute Engine for server-to-cloud lift-and-shift.
  • Secondary: Transfer Service for on-premises data dump to Cloud Storage.
  • Justification: For VM migrations, Migrate for Compute Engine provides replicated storage volumes; Transfer Service handles unstructured data efficiently.
  • Artefacts: Migration architecture diagram, Transfer Service endpoint configuration, network diagram.

Alibaba Cloud Example: Data migration media:

  • Primary: Database Migration Center (DMC) with dedicated import tool.
  • Secondary: OSS ETL service for large data volume transfers.
  • Justification: DMC supports schema translators; OSS enables batch processing of unstructured data.
  • Artefacts: Migration topology map, DMC task settings screenshot, OSS bucket configuration.

4.8.2 What are the encryption algorithms deployed on data transfer media? Please provide the artefacts on the encryption algorithm used. Please refer to Data Protection standards and ensure the business conforms to this encryption standard.

Enter text here.

AWS Example: Data transfer encryption:

  • Media encryption: TLS 1.2/1.3 with ephemeral key exchange.
  • All transfer tools use AWS KMS-managed certificates.
  • Specific: When using DMS, data encrypted over VPN tunnel; S3 multipart upload uses SSE-KMS (AES-256-GCM) with bucket-level KMS key.
  • Artefacts: Certificate issuance via ACM, KMS key policy screenshot, DMS task encryption settings diagram.

GCP Example: Transfer encryption implementation:

  • TLS 1.3 for all network paths.
  • SSE-CMEK (Customer-Managed Encryption Key) for Cloud Storage uploads.
  • When using Transfer Service, service accounts use signed URLs with TLS termination.
  • Artefacts: SSL Labs report showing TLS Configuration, Cloud KMS key settings screenshot.

Alibaba Cloud Example: Media encryption approach:

  • TLS 1.2+ for all network traffic.
  • SSE-KMS (Alibaba Cloud KMS) for OSS transfers.
  • DMC uses internally encrypted channels with CMKs.
  • Artefacts: KMS key usage audit logs, OSS transfer encryption settings view.

4.8.3 Describe the process or procedure (e.g. salting, padding, checksum) in maintaining data integrity as part of the data validation process. Please provide the artefacts on the process in data validation.

Enter your answer here.

Example:

  • Pre-migration: Full row count and checksum (MD5 hash) of all records calculated on source before migration.
  • During migration: Each batch of records is verified using a rolling checksum. Any mismatch triggers a re-transfer of that batch.
  • Post-migration: Full row count match verified (source vs destination). Checksum comparison on 100% of migrated records.
  • Data validation query: SELECT COUNT(*), MD5(CONCAT(col1, col2, ...)) FROM table run on both source and target.
  • Artefacts: Pre/post migration row count report (CSV), checksum comparison log, any mismatch resolution tickets.

4.8.4 Are there sensitive data involved in data migration? Declare as Yes or No and indicate applicable data types/fields. If Yes, will the data be migrated in "clear" or encrypted format?

Enter your answer here.

Example: Yes. Sensitive data types involved in migration:

Data Category Fields Sensitivity Level Migration Format
Customer PII Name, Email, Phone, Address, CCCD/ID Restricted Encrypted (AES-256-GCM at field level)
Payment tokens Credit card tokens (from payment gateway) Highly Restricted Encrypted (AES-256-GCM with application key)
Policy data Policy number, coverage details Internal Encrypted at transport (TLS 1.3) + at rest (SSE-KMS)

All data is migrated in encrypted format. No data is transferred in clear text.

4.8.5 Business / Application owner to provide backup and restoration plan to support data migration.

Enter your answer here.

Example: Full backup of source database is taken immediately before migration begins. The backup is stored in encrypted cloud storage (AWS S3 SSE-KMS / GCP Cloud Storage CMEK / Alibaba OSS SSE-KMS) with 90-day retention. Restoration plan:

  • Rollback scenario 1 (pre-migration): Restore full backup to source — estimated 2 hours.
  • Rollback scenario 2 (partial migration): Restore only the migrated batches from backup — estimated 1 hour per batch.
  • Testing: Backup restoration is tested in a staging environment 1 week before the actual migration.
  • Artefacts: Backup completion logs, restoration runbook, test restoration report.

4.8.6 Business / Application owner to provide any downtime required.

Enter your answer here.

Example:

  • Planned downtime window: Saturday 02:00 – 06:00 AM (local time) — 4 hours total.
  • Service impact: Customer portal and mobile app will be in read-only mode during migration. New application submissions will be queued and processed after migration completes.
  • User communication: Banner notification displayed 48 hours before downtime. Email notification sent 24 hours before to registered users.
  • Estimated downtime: ~2 hours for data migration + ~1 hour for validation + ~1 hour buffer.

4.8.7 Provide RBAC matrix on accounts and personnel involved in this data migration activity.

Enter your answer here.

Example:

Role Personnel Access Required Duration
Migration Lead Senior SRE Engineer Full read/write on source + target DB, S3/Cloud Storage bucket Migration window + 7 days
DB Administrator DBA Team Source DB read access, target DB schema management Migration window
Security Observer Security Engineer (audit) Read-only access to logs and migration output Migration window + 30 days
Application Owner Software Engineering Lead Read-only dashboard, approve/reject rollback Migration window

All temporary access is revoked within 7 days post-migration. A Jira ticket tracks each access grant.

4.8.8 Source and destination host must have valid CA certificate deployed. Certificate pinning is mandatory. Provide artifacts for assurance.

Enter your answer here.

Example: Yes, both source and destination hosts have valid CA certificates deployed.

  • Source: On-premises database server certificate signed by internal CA (Certificate expiry: 2027-01-15). Certificate pinning hash (SHA-256:abc123...) configured in migration client.
  • Destination: AWS RDS / GCP Cloud SQL / Alibaba ApsaraDB — managed service certificates are signed by the cloud provider's public CA. TLS 1.3 enforced for all connections.
  • Artefacts: Screenshot of source server certificate chain. Destination cloud DB SSL/TLS configuration. Certificate pinning configuration file snippet.

4.8.9 Validate data migration script developed internally or provided by vendor. Provide artifacts to support script functionalities.

Enter your answer here.

Example: Migration scripts are developed by Software Engineering team and reviewed by SRE team.

  • Code review: All scripts passed peer review via GitHub/GitLab merge request with 2 approvals.
  • Testing: Scripts ran successfully in non-production environment (UAT) with 1 million records (10% of expected production volume).
  • Security scanning: Scripts scanned with SAST tool (SonarQube/Semgrep) — zero high-severity findings.
  • Artefacts: Link to MR approvals, UAT migration test results report, SAST scan output confirming no critical issues.

4.8.10 All system and transactional logs related to data migration must be logged into SIEM. Please provide the artefacts.

Enter your answer here.

Example: All data migration logs are forwarded to central logging / SIEM:

  • Source DB audit logs: Streamed to CloudWatch Logs / Cloud Audit Logs / Log Service (SLS) in real-time.
  • DMS task logs: AWS DMS task logs -> CloudWatch Logs -> Kinesis Firehose -> Splunk HEC. GCP Transfer Service logs -> Cloud Logging -> Pub/Sub -> SIEM.
  • Application migration scripts: Custom logs written to CloudWatch Logs using structured JSON format, forwarded to SIEM via subscription filter.
  • Artefacts: Screenshot of SIEM dashboard showing migration log stream, confirmation of log ingestion, sample log entries for audit.

4.8.11 Data owner must engage privacy, legal and compliance team for advisory on data deletion. (Optional when no data deletion is required.)

Enter your answer here.

Example: Yes, data owner has engaged privacy and legal teams for post-migration data deletion.

  • Status: Privacy team has been notified via legal ticket LEGAL-DATA-2026-089.
  • Deletion plan: Source database will be retained for 90 days post-migration (rollback window), then purged using secure data deletion procedure (overwrite + drop).
  • Retention: Backup data will be retained for 1 year per regulatory requirement, then deleted.
  • Artefacts: Legal ticket reference, approved data deletion plan, post-deletion confirmation report.

4.8.12 Are the access control permissions enrolled into identity management system for access management? If yes, please provide artifacts on the enrolment. If no, please provide justification.

Enter your answer here.

Example: Yes, all access control permissions for migration activities are managed through the identity management system.

  • IAM roles: Temporary IAM roles / GCP Service Accounts / Alibaba RAM roles were created for the migration window. Each role has the minimum required permissions.
  • Access approval: Approved via ITSM ticket CHG-2026-0615-042 with SRE and Security team sign-off.
  • Expiration: All temporary roles are set to auto-expire 7 days after the migration window.
  • Justification (if no): [Explain why IAM is not used and how access is controlled instead.]
  • Artefacts: Screenshot of IAM role configuration with expiration policy, ITSM approval ticket link.

4.9 Business Continuity Plans (BCP)/High Availability (HA)

This section is only required for business-critical applications which need to prepare BCP and DR/HA. ⚠️

4.9.1 Are encryption keys backed up to separate storage? Provide justification should the backup not be viable.

Optional — only if application is categorised as critical and requires HA.

Provide relevant artefacts.

Important points to note:

  • Key backup capability will only be applicable to cloud environments (AWS, GCP, Alibaba Cloud).
  • Backup of encryption keys into separate storage serves as risk mitigation for the business in scenarios like inaccessibility to cloud key management service or key corruption.
  • Business will accept the risk of data inaccessibility and/or data loss when encryption key is unavailable or corrupted.
  • Business to provide screenshot of keys backup and artifacts demonstrating business owner has full control over the backup copies of encryption keys.

AWS Example:

  • KMS key backup exported to S3 bucket in a separate account (DR account) using cross-account key policy.
  • Backup encrypted with a separate KMS key in the DR account.
  • Artefacts: Screenshot of KMS key policy, cross-account backup configuration.

GCP Example:

  • Cloud KMS key versions exported to Cloud Storage bucket in a separate project using gcloud CLI.
  • Key wrapped with a project-specific CMEK before export.
  • Artefacts: Screenshot of Cloud KMS key version list, export command output.

Alibaba Cloud Example:

  • KMS key material backed up to OSS bucket in a different region.
  • Cross-region OSS replication ensures key availability if primary region fails.
  • Artefacts: Screenshot of KMS key backup settings in the console.

4.9.2 Is a business continuity plan (BCP) in place for encryption keys restoration? Keys restoration plan will include scenario where keys are corrupted or lost. Provide justification should the BCP plan not be available.

Optional — only if application is categorised as critical and requires HA.

Provide relevant artefacts.

Example:

  • BCP for key restoration is documented in the incident response runbook (section 4.3 — Key Compromise).
  • Restoration steps include re-importing KMS key material from the backup storage, re-establishing IAM policies, and verifying data decryption in a test environment.
  • Annual tabletop exercise validates the procedure. Last exercise: 2026-03-15.
  • Artefacts: Link to runbook, tabletop exercise report.

4.9.3 Is a High Availability (HA) deployment plan available for encryption keys? HA can be in the form of transparent failover. Elaborate HA plan and attach supporting artefacts.

Optional — only if application is categorised as critical and requires HA.

Provide relevant artefacts including screenshot.

AWS Example:

  • AWS KMS multi-Region keys with automatic replication between us-east-1 and us-west-2.
  • Transparent failover — application SDK falls back to the secondary region key automatically.
  • Artefacts: Screenshot of multi-Region key configuration.

GCP Example:

  • Cloud KMS key ring created in a multi-region location (e.g., global).
  • CMEK keys are automatically replicated across GCP regions within that location.
  • Client library with automatic retry and regional fallback.
  • Artefacts: Screenshot of key ring location settings and IAM binding.

Alibaba Cloud Example:

  • KMS key replicated to secondary region using key material backup and restore.
  • Application configured to retry key operations against the secondary KMS endpoint on failure.
  • Artefacts: Screenshot of cross-region key replication configuration.

4.10 Sensitive Data Inventory

This section must be completed by Software Engineering team. Refer to Data Protection Standards and list the type of data that the application will transact / store.

Note: Input the type of data only in this section, not the actual data. Do not include details of actual or sensitive data in this section.

Data Type Type of Data (Structured / Unstructured) Data Classification Data Storage Locality (Specify the data storage country) Data Storage Service (IaaS, PaaS DB, Storage and/or On-Premises) Type of Encryption Mechanism (Data at rest) Remarks
Example: UserID, First Name, Last Name, Credit Card, etc. Structured Restricted/Sensitive Singapore AWS RDS MySQL AWS KMS + transparent data encryption

4.11 Application Logs Containing Security-Relevant Content

This section is required to be completed by Software Engineering team in collaboration with Security team.

If additional logging is required outside of the standard OS and AD logging, or for SaaS applications where configuration changes or authentication logging is required, please note that bespoke monitoring outside of the standard built-in logging is typically chargeable and an RFP is required.

4.11.1 Application on Operating System

Complete below table with details of application logs which are required in addition to the Infra OS Logs covered in 4.5.2.

Note: the application should be configured to send the application logs to the appropriate logging mechanism in the Cloud.

Path of Log File Log File Name Description / Security Content
/var/log/app/security.log Security Events Auth failures, privilege escalation, PII access, config changes
/var/log/app/audit.log Audit Trail User actions, API calls, data exports
/opt/app/logs/access.json Application Access Request metadata, latency, error codes

4.11.2 Application on Container Platform

Note: the application should be configured to send the application logs to the appropriate logging mechanism in the Cloud.

Business Unit Environment (Prod / Non-Prod) Resource ID (Cloud-agnostic)
Customer Portal Prod arn:aws:eks:us-east-1:123456789:cluster/prod-cluster
Customer Portal Non-Prod arn:aws:eks:us-east-1:123456789:cluster/uat-cluster
Customer Portal Prod projects/my-project/locations/us-central1/clusters/prod-gke-cluster
Customer Portal Non-Prod projects/my-project/locations/us-central1/clusters/uat-gke-cluster
Customer Portal Prod alicloud:cs:cn-hangzhou:123456789:cluster/prod-ack-cluster
Customer Portal Non-Prod alicloud:cs:cn-hangzhou:123456789:cluster/uat-ack-cluster

4.11.3 KubePodInventory (Inventory of pods in a Kubernetes cluster)

Note: the application should be configured to send the application logs to the appropriate logging mechanism in the Cloud.

Business Unit Environment (Prod / Non-Prod) Cluster ID
Customer Portal Prod prod-eks-cluster / prod-gke-cluster / prod-ack-cluster
Customer Portal Non-Prod uat-eks-cluster / uat-gke-cluster / uat-ack-cluster

Note that it is required for the Software Engineering team to work with the Security team to create monitoring use cases.

4.12 Compliance Checklist

This section is required to be completed by Software Engineering team.

The purpose of this section is to ensure the appropriate compliance checks are carried out as part of the solution delivery process.

Has any local regulatory compliance been considered? Consider local regulatory compliance, especially for projects handling personal identifiable information (PII), health data and financial data including credit card numbers.

  • Yes
  • No

Are there any non-compliances against information security policies that have been identified? Exceptions must be raised and fully approved in accordance with the exception management process. Please share the exception or deviation number.

Exception / Deviation Number(s): _______________________________________

5. Continuous Integration/Continuous Deployment (CI/CD) - DevOps

This section is required to be completed by Software Engineering team. 🔄

5.1 Artifact Repository

Virtual Repo Remote Repo Local Repo Permission/Group Name
libs-release maven-central libs-release-local ci-pipeline-rw

5.2 CI/CD Pipeline Configuration

Pipeline Name Pipeline Type Deployment Environment Tools Used
deploy-prod Jenkins Pipeline Production Maven, Docker, Helm, ArgoCD
deploy-uat GitHub Actions UAT npm, Docker, Terraform

Agent Assignment: DevOps Team

Agent Capabilities Requirement: Read-only access to source; Write access to Container Registry.

5.3 Source Code Repository

Project Repository Repository Type Remarks
customer-portal github.com/org/customer-portal GitHub Main monolithic web app
auth-service github.com/org/auth-service GitHub Identity microservice

🧾 Acronyms & Glossary

Acronym Expansion
ACK Alibaba Cloud Container Service for Kubernetes
ACM AWS Certificate Manager
ALB Application Load Balancer
BCP Business Continuity Plan
CAS Certificate Authority Service
CDC Change Data Capture
CIDR Classless Inter-Domain Routing
CMK Customer Managed Key
CMEK Customer-Managed Encryption Key
DDoS Distributed Denial of Service
DLP Data Loss Prevention
DMC Database Migration Center
DMS Database Migration Service
DNS Domain Name System
DR Disaster Recovery
EBS Elastic Block Store
EC2 Elastic Compute Cloud
ECR Elastic Container Registry
ECS Elastic Container Service (AWS) / Elastic Compute Service (Alibaba)
EIP Elastic IP
EKS Elastic Kubernetes Service
GCP Google Cloud Platform
GFE Google Front End
GKE Google Kubernetes Engine
GSLB Global Server Load Balancer
HA High Availability
HEC HTTP Event Collector (Splunk)
HSM Hardware Security Module
IaaS Infrastructure as a Service
IAM Identity & Access Management
IAP Identity-Aware Proxy
IDP Identity Provider
ILB Internal Load Balancer
JWT JSON Web Token
KMS Key Management Service
K8s Kubernetes
LB Load Balancer
LLM Large Language Model
MFA Multi-Factor Authentication
NER Named Entity Recognition
OIDC OpenID Connect
OSS Object Storage Service
OTP One-Time Password
PaaS Platform as a Service
PAI Platform for AI
PAM Privileged Account Management
PCI DSS Payment Card Industry Data Security Standard
PID Privileged ID
PII Personally Identifiable Information
RAG Retrieval-Augmented Generation
RAM Resource Access Management
RBAC Role-Based Access Control
RDS Relational Database Service
RPO Recovery Point Objective
RTO Recovery Time Objective
SaaS Software as a Service
SAST Static Application Security Testing
S3 Simple Storage Service
SDU Sensitive Data Unified (Alibaba)
SIEM Security Information and Event Management
SLB Server Load Balancer
SLS Log Service (Alibaba)
SNS Simple Notification Service
SOC Security Operations Center / Service Organization Control
SQLi SQL Injection
SRE Site Reliability Engineering
SSM AWS Systems Manager
SSE Server-Side Encryption
SSL/TLS Secure Sockets Layer / Transport Layer Security
STS Security Token Service
SWE Software Engineering
TDE Transparent Data Encryption
TOTP Time-based One-Time Password
VPC Virtual Private Cloud
VPN Virtual Private Network
WAF Web Application Firewall
XSS Cross-Site Scripting

💡 Tip: Add project-specific acronyms as needed. Keep the list sorted alphabetically.

6. Operational Readiness

This section is required to be completed by Software Engineering team in collaboration with Site Reliability Engineering (SRE) and Security teams. 🚀

The purpose of this section is to ensure the appropriate teams are engaged or processes are triggered for solution delivery and operational readiness.

📝 Note: Sections 6.2 (High Availability Validation) and 6.3 (Automation Review) are reserved for future use. A commented-out copy exists below §6.1 — uncomment when validation is required for your project.

Item Yes/No Remarks
Availability Monitoring? Yes / No Enter Remarks here.
Backup Required based on BIA assessment Yes / No Enter Remarks here.
New DNS records required? Yes / No Enter Remarks here.
New TLS certificates required? Yes / No Enter Remarks here.
New firewall rules required? Yes / No Enter Remarks here.
Proxy changes (for user, server or application required)? Yes / No Enter Remarks here.
New database instance required on any shared DBMS platforms? Yes / No Enter Remarks here.
Does the solution require engagement with a new vendor? Third party risk assessment is mandatory for this requirement. Yes / No Enter Remarks here.

6.1 Infrastructure Logs

This section is required to be completed by Software Engineering team with Site Reliability Engineering (SRE) team support.

Describe how infrastructure logs are collected for this solution on your chosen cloud provider.

Enter your answer here.

Example (AWS):

  • EC2 / EKS node OS logs: Collected by CloudWatch Agent (unified) deployed via SSM, forwarding /var/log/messages, /var/log/secure, /var/log/containers/*.log to CloudWatch Log Groups with 1-year retention.
  • VPC Flow Logs: Enabled for all VPCs, published to CloudWatch Logs and S3 (via Kinesis Firehose) for 7-year compliance retention.
  • CloudTrail: Enabled for all regions with management and data events, delivered to S3 bucket with 7-year retention lock.
  • AWS Config: Configuration recorder enabled with snapshot delivery to S3 every 6 hours.

Example (GCP):

  • Compute Engine / GKE node OS logs: Fluent Bit daemonset collects /var/log/syslog, /var/log/auth.log and streams to Cloud Logging with 1-year retention.
  • VPC Flow Logs: Enabled for all VPC subnets, sampled at 50%, exported to Cloud Storage archive bucket with 7-year retention.
  • Cloud Audit Logs: Admin Activity, Data Access, and System Event audit logs retained for 7 years via log sink to BigQuery.

Example (Alibaba Cloud):

  • ECS / ACK node OS logs: Log Service (SLS) Logtail collects /var/log/messages, /var/log/secure and forwards to SLS project with 1-year retention.
  • VPC Flow Logs: Enabled via VPC console, stored in Log Service for 180 days.
  • ActionTrail: Enabled for all regions, delivers to Log Service under "audit-log" project with 7-year OSS archive.

6.4 Support

This section is required to be completed by Software Engineering team in collaboration with Site Reliability Engineering (SRE) team.

Define the support model and support contacts for this solution, where appropriate to the solution, especially if introducing a new capability or a new technology. If the support is not relevant or applicable, state so within the relevant section below.

6.4.1 Internal Support

Support Level Details
1st line support and incident handling? SRE Team (24/7)
2nd line support (solution SMEs / application teams, etc.) Software Engineering Team (8am-6pm local time)
3rd line (where applicable to be provided internally) Security Team (on-call)

6.4.2 Vendor / External Partner Support

Item Details
Support contact details support@cloud-provider.com (24/7)
Support Service Level Agreement 4-hour response, 24-hour resolution for P1
Account manager account-manager@cloud-provider.com
Escalation matrix provided by vendor or partner Yes, documented in Confluence (link: https://confluence.example.com/support-escalation)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment