Cloud Governance, FinOps & Establishing a Security Posture Baseline

Why Governance Must Precede Workloads

Organisations that migrate workloads to the cloud and implement governance afterwards are already operating in a remediation posture. A misconfigured S3 bucket in production cannot be made private retroactively without risk. Governance — the set of policies, guardrails, and standards that constrain what can be deployed — must be established before the first production workload is created.

The 2019 Capital One breach exposed 106 million customer records because a misconfigured Web Application Firewall allowed a Server-Side Request Forgery (SSRF) attack to reach the Instance Metadata Service. A properly configured Service Control Policy (SCP) that blocked IMDS v1 access would have significantly limited the blast radius.

AWS Organizations and Service Control Policies

AWS Organizations is the management layer for multiple AWS accounts. An organisation has a root, Organizational Units (OUs), and member accounts. Service Control Policies (SCPs) are permission boundaries applied at the OU or account level — they restrict what IAM permissions are available, regardless of what individual IAM policies grant.

Example SCP: Deny all actions from regions outside ap-south-1 and ap-southeast-1

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-south-1", "ap-southeast-1"]
    }
  }
}

This SCP prevents any IAM user or role in the affected accounts from launching resources in non-approved regions — even if their IAM policy grants full admin access. SCPs are a critical control for DPDP Act 2023 compliance: Indian personal data must not be processed in regions outside India without explicit consent.

AWS Well-Architected Framework: Security Pillar

AWS WAF (not to be confused with the Web Application Firewall) defines six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimisation, and Sustainability. The Security Pillar organises cloud security across seven design principles:

Design Principle	Implementation
Implement a strong identity foundation	Centralise identity; use IAM Identity Center; eliminate root user usage
Enable traceability	CloudTrail in all regions; Config continuous recording
Apply security at all layers	VPC, Security Group, OS, application, data — all have controls
Automate security best practices	AWS Config rules, GuardDuty, Security Hub
Protect data in transit and at rest	TLS everywhere; KMS encryption for all storage
Keep people away from data	Use roles and automation; avoid direct data access by humans
Prepare for security events	Runbooks, IR playbooks, game days

Security Posture Baseline

Before any workload is deployed into an AWS account, the following baseline should be in place:

Control	Verification
MFA on root account	IAM → Security recommendations
No root account access keys	IAM → Security credentials
CloudTrail enabled, all regions	CloudTrail → Trails
S3 Block Public Access at account level	S3 → Block Public Access settings
GuardDuty enabled in all regions	GuardDuty → Detector status
Config enabled with all resource types	Config → Settings
Security Hub enabled	Security Hub → Summary
VPC default security group: deny all	EC2 → Security Groups
No EC2 instances with instance profile having admin policy	IAM Access Analyzer
Budget alert at 80% and 110% of expected spend	Billing → Budgets

This baseline maps to CIS AWS Foundations Benchmark Level 1 — the internationally recognised minimum security standard for AWS accounts.

FinOps and Cloud Security

Financial Operations (FinOps) is often treated as a separate concern from security, but they are closely related:

• Billing anomalies are security signals: A sudden spike in EC2 instance launches or S3 data transfer often indicates an account compromise. Enable AWS Cost Anomaly Detection with SNS alerts.
• Untagged resources evade security policy: Governance requires that every resource carries cost centre, environment, and owner tags. Untagged resources cannot be mapped to security responsibilities.
• Economic Denial of Sustainability (EDoS): An attacker with compromised credentials can incur massive cloud bills to cause financial harm. Budget alerts and automatic spending limits (via SCPs or AWS Service Quotas) mitigate this.

Cloud Centre of Excellence (CCoE)

Larger organisations should establish a Cloud Centre of Excellence — a cross-functional team responsible for:

CCoE Function	Responsibility
Landing Zone	Standard account structure, network, logging baselines
Security Engineering	SCP design, guardrail automation, security tool rollout
Identity	IdP federation, access review cadence
Cost Management	Tagging standards, budget governance, reserved capacity planning
Developer Enablement	Self-service pipelines, approved service catalogue

The CCoE does not own every cloud deployment. It owns the standards and guardrails within which development teams operate autonomously.

Indian Regulatory Context

For Indian regulated entities, the governance framework must satisfy:

Regulation	Key Cloud Governance Requirement
DPDP Act 2023	Data localisation for personal data; Data Fiduciary accountable for processor controls
CERT-In 2022 Directions	6-hour breach reporting; 180-day log retention; ICT infrastructure audit
RBI IT Framework (2021)	Board-approved cloud risk policy; audit trails; third-party risk management
SEBI CSCRF 2024	Classified market infrastructure; cloud providers must meet baseline security norms
MeitY Cloud Policy 2023	Government data classification; empanelled provider list for sensitive workloads