Why MCM Governance
The problems with enforcing cloud governance per provider and how MCM Governance solves them.
Why MCM Governance
Cloud governance — ensuring that every resource is correctly configured, tagged, encrypted, and compliant — is hard enough on a single provider. Across AWS, Azure, and hybrid Linux hosts, it becomes a coordination problem. Each provider has its own policy engine, its own compliance reports, and its own scheduling mechanism. The result is a fragmented set of rules that nobody has a unified view of.
Challenges & How MCM Solves Them
Each challenge below is a real friction point teams face when enforcing governance across providers and hosts without a unified layer.
1. Different Policy Languages
AWS uses Config Rules and SCPs; Azure uses Azure Policy and Blueprints; host machines require custom shell scripts. Teams must maintain expertise in each system separately.
How MCM solves it: Cloud resources use Cloud Custodian YAML; hosts use shell scripts. Write a policy once and deploy it across all accounts of the same type — no need to maintain parallel implementations per provider.
2. No Unified Compliance View
Compliance scores live in separate provider dashboards with no way to aggregate them into a single organisational posture.
How MCM solves it: Policy Groups surface a single aggregated compliance score across all policies in the group, giving a clear organisational posture without piecing together reports from multiple dashboards.
3. No Cross-Provider Grouping
You cannot bundle an AWS encryption policy and an Azure storage policy into one logical compliance pack with a single score.
How MCM solves it: Policy Groups let you bundle related policies — regardless of provider — into named packs (e.g. "Security Baseline", "GDPR Pack"). The group tracks a single aggregated compliance score across all included policies.
4. Manual Scheduling
Each provider's policy evaluation runs on its own cadence with no central control or visibility.
How MCM solves it: All policies run on a cron schedule managed by MCM with timezone support. Any policy can also be triggered manually at any time from the same interface — no provider-specific scheduling tools needed.
5. Fragmented Audit Trails
Execution history is spread across provider consoles, making it hard to produce a coherent audit log.
How MCM solves it: Every policy run — success, partial, or failed — is logged centrally with duration, resource count, and error details. A single execution history covers all providers and hosts.
6. Host Coverage Gaps
Ubuntu and Windows hosts fall entirely outside cloud provider governance tools, requiring separate scripts and manual checks.
How MCM solves it: MCM provides first-class host policy support for Ubuntu. Each host policy includes a compliance check script and an optional remediation script. Enable auto-remediation to fix violations automatically on failure.
7. Framework Mapping Overhead
Mapping controls to GDPR, HIPAA, or SOC 2 requires manually aligning policies across every provider — there is no pre-built framework.
How MCM solves it: GDPR, HIPAA, and SOC 2 policy groups are pre-built and ready to activate, covering encryption, access control, logging, and backup requirements out of the box. No manual mapping required.
MCM vs Managing Governance Individually
| Aspect | Individual Provider Tools | MCM Governance |
|---|---|---|
| Policy language | AWS Config, Azure Policy, custom scripts | Unified: Cloud Custodian YAML + shell scripts |
| Policy grouping | Flat list per provider | Groups with aggregated compliance scores |
| Multi-cloud view | Separate compliance dashboards | Single compliance dashboard across all providers |
| Compliance scoring | Per-policy, manual aggregation | Automatic group-level compliance score |
| Scheduling | Provider-specific mechanisms | Unified cron scheduler with timezone support |
| Audit trail | Fragmented across provider consoles | Centralised execution history |
| Host coverage | Not supported natively | First-class host policy support with auto-remediation |
| Compliance frameworks | Manual mapping required | Built-in GDPR, HIPAA, SOC 2 groups |
Features
| Feature | Description |
|---|---|
| Policy Groups | Bundle policies into named groups with a single aggregated compliance score |
| CSP Policies | Cloud Custodian YAML policies targeting AWS and Azure resources (EC2, storage, IAM, etc.) |
| Host Policies | Shell script policies for Ubuntu hosts with optional auto-remediation |
| Compliance scoring | Automatic score per group calculated from execution success/partial/failure rates |
| Built-in frameworks | Pre-built GDPR, HIPAA, and SOC 2 policy groups ready to activate |
| Cron scheduling | Timezone-aware cron schedule per policy with manual trigger at any time |
| Execution history | Centralised log of every run with status, duration, resource count, and errors |
| Auto-remediation | Host policies can declare a remediation script that runs automatically on failure |
| Severity levels | Tag each policy as Low, Medium, or High severity for prioritisation |
| Policy categories | Classify policies as Security, Cost, Compliance, Access, Networking, or Tags |
Built-In Standard Policy Groups
MCM ships with pre-built policy groups aligned to widely used compliance frameworks — GDPR, HIPAA, and SOC 2. Each group is a curated bundle of Cloud Custodian and host policies that together cover the key controls for that framework: encryption at rest and in transit, access logging, IAM least-privilege, backup retention, and more.
Activating a built-in group immediately starts evaluating your connected accounts against all policies in that group and surfacing a compliance score. No mapping, no authoring, no research into what each framework requires.
What you get: Out-of-the-box compliance coverage for the most common regulatory frameworks. You can demonstrate a compliance posture on day one without writing a single policy.
Custom Cloud Custodian Based Cloud Policies
For requirements that go beyond the built-in groups, MCM lets you write Cloud Custodian YAML policies targeting AWS and Azure resources. Cloud Custodian is an open-source policy engine with a large ecosystem of supported resource types and actions — MCM integrates it natively so you get all its expressiveness without managing the infrastructure to run it.
A custom cloud policy specifies:
- The resource type to target (EC2 instances, S3 buckets, Azure VMs, storage accounts, IAM roles, etc.)
- A set of filters that select which resources to evaluate
- Optional actions to take on non-compliant resources (notify, tag, stop, delete)
Policies are assigned to one or more accounts, given a severity level, classified by category, and scheduled with a cron expression. Every run is recorded in the central execution history.
What you get: The ability to express any compliance or governance rule your organisation has — no matter how custom — and enforce it automatically across all connected accounts without deploying or maintaining policy infrastructure.
Custom Shell Script Based Host Policies
Ubuntu and other Linux hosts fall outside the reach of cloud provider policy engines. MCM fills this gap with host policies: shell scripts that run on Ubuntu hosts via SSH or a deployed agent to check and optionally remediate compliance conditions.
Each host policy consists of two scripts:
- Check script — runs on the host and exits with 0 (compliant) or non-zero (violation)
- Remediation script (optional) — runs automatically when the check fails, to bring the host back into compliance
Host policies can be scheduled the same way as cloud policies and appear in the same unified execution history and compliance scoring.
What you get: Governance coverage that extends beyond cloud APIs to the actual operating system — patch levels, file permissions, running services, CIS benchmark controls, and any custom check your security team needs.