Every cloud management platform (CMP) needs access to your cloud accounts to do its job. Cost visibility requires billing data. Commitment management requires purchase permissions. Right-sizing recommendations require resource metadata. A CMP needs a certain degree of data access — but is that access designed with the same rigor you’d apply to any third-party integration touching production infrastructure?

This buyer’s guide covers what to ask, what to verify, and how to evaluate CMP security posture without slowing down the FinOps automation that makes these platforms valuable in the first place.

Why CMP Security Matters More Than You Think

According to FinOps Foundation’s Tools and Services working group: “FinOps tooling will require access to a large amount of potentially sensitive data, and potentially permissions to act autonomously in the organization’s cloud environment.”

 

That’s the core tension. You’re granting a third-party platform access to billing data, resource inventories, and potentially write permissions — all to reduce cost and improve efficiency. The security review can’t be an afterthought, but it also can’t be so onerous that it blocks adoption for six months while your team burns money on unoptimized spend.


The FinOps Foundation’s Governance, Policy & Risk capability explicitly calls out “Security Risk” as: “Use of technology in ways inconsistent with the organization’s security posture, creating exposure across other risk categories.” A CMP that requires overly broad permissions or lacks proper audit trails creates exactly this kind of risk.

What Permissions Does a CMP Actually Need?

Not all CMPs need the same level of access. The permissions required depend on what the platform does:

Read-Only Platforms (Visibility and Reporting)

Platforms that only provide cost dashboards, forecasting, and allocation typically need:

  • Billing data access — Cost and Usage Reports (CUR) or equivalent billing exports
  • Resource metadata — instance types, tags, account structure
  • Monitoring data — CloudWatch metrics for right-sizing recommendations

These platforms can operate with genuinely read-only IAM roles. They can’t modify your infrastructure, purchase commitments, or change configurations. The security footprint is small.

Automated Platforms (Commitment Management and Optimization)

Platforms that actively purchase Reserved Instances (RIs), Savings Plans, or make optimization changes require:

  • Everything above, plus:
  • Purchase permissions — ability to buy commitments on your behalf
  • Potentially write access — for automated right-sizing, scheduling, or resource modifications

These platforms have a larger security footprint. They’re doing more, which means they need more — but the permissions should still be scoped tightly to the specific actions the platform performs.

The Least Privilege Question

Every vendor will claim they follow least privilege. Here’s how to verify it:

  1. Request the exact IAM policy document — not a summary, the actual JSON policy that gets attached to the role. If a vendor won’t share this, that’s a red flag.
  2. Check for wildcard permissions — `”Action”: “*”` or `”Resource”: “*”` may mean a policy isn’t genuinely scoped.
  3. Verify resource-level restrictions — can the role access only billing data, or does it have permissions across all services?
  4. Check for condition keys — well-designed policies use conditions (like `aws:SourceAccount`) to prevent confused deputy attacks.

How Should the Platform Authenticate?

The authentication mechanism matters as much as the permissions granted. Here’s what to look for:
MethodSecurity LevelWhat to Verify
Cross-account IAM role with external IDStrongExternal ID is unique per customer; trust policy is scoped
Service principal with reader roleStrongNo write permissions unless explicitly needed for automation
API keys stored in the vendor’s environmentWeakerRotation policy, encryption at rest, and access logging
Admin credentials shared during onboardingUnacceptableWalk away

The strongest pattern for AWS is a cross-account IAM role where:

  • You create the role in your account (you control it)
  • The vendor’s account is specified in the trust policy
  • An external ID prevents unauthorized assumption
  • You can revoke access instantly by deleting the role

If a platform asks you to share credentials, create users in their account, or install agents with root access — those are design decisions that prioritize vendor convenience over your security.

Auditability: Can You See What the Platform Does?

A secure CMP should make its activity fully auditable. That means:

CloudTrail integration — every API call the platform makes should appear in your CloudTrail logs. You shouldn’t need the vendor’s cooperation to audit their access patterns.

Activity logging within the platform — the CMP itself should log what actions it took, when, and why. For automated platforms making purchases, this means a clear record of every commitment purchased with the reasoning.

Alerting on unexpected activity — you should be able to set up alerts if the CMP’s role makes API calls outside its expected scope.

Compliance Certifications: What to Require

Compliance certifications signal that a vendor has been independently audited. They’re necessary but not sufficient — a SOC 2 report doesn’t guarantee the vendor’s IAM policy in your account is well-designed. But absence of certifications is a clear disqualifier for sensitive environments.

Minimum Certifications to Require

  • SOC 2 Type II — demonstrates ongoing controls for security, availability, and confidentiality over a period (not just a point-in-time snapshot)
  • ISO 27001 — information security management system certification
  • GDPR compliance — if the platform processes data subject to European privacy regulations

What SOC 2 Actually Covers

SOC 2 is built on five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. For a CMP evaluation, focus on:

  • Security — are the vendor’s systems protected against unauthorized access?
  • Confidentiality — is your billing and resource data protected from unauthorized disclosure?
  • Availability — can you rely on the platform being accessible when you need it?

A Type II report covers a period (usually 6-12 months), meaning controls were operating effectively over time — not just working on the day the auditor visited.

Industry-Specific Requirements

Depending on your industry, you may also need:

  • HIPAA BAA — if cloud billing data could contain PHI (healthcare)
  • FedRAMP — government workloads
  • PCI DSS — if the platform touches environments processing payment data

Governance and Compliance Reporting: A Bonus, Not a Given

Some CMPs go beyond managing their own security posture and help you manage yours. This is useful but distinct from the platform’s own security. Features to look for:

  • Well-Architected Framework assessments — automated checks against AWS security best practices
  • Compliance drift detection — alerts when resources deviate from approved configurations
  • Tag governance — enforcement of tagging policies that support cost allocation AND compliance
  • Custom policy rules — ability to define organization-specific compliance rules

Don’t confuse a platform’s compliance features (what it helps you monitor) with the platform’s own compliance posture (how secure it is). Both matter, but they’re separate evaluation criteria.

The Security Evaluation Checklist

Use this during vendor evaluations. A “no” on any critical item should pause the conversation:

Critical (Must-Have)

  • [ ] SOC 2 Type II report available for review
  • [ ] Cross-account role (or equivalent) — no credential sharing
  • [ ] IAM policy document provided in full
  • [ ] No wildcard permissions in the policy
  • [ ] All activity visible in your CloudTrail/audit logs
  • [ ] Data encrypted in transit and at rest
  • [ ] Can revoke access instantly without vendor cooperation

Important (Should-Have)

  • [ ] External ID used in cross-account trust policy
  • [ ] Separate roles for read-only vs. write operations
  • [ ] Activity logging within the platform itself
  • [ ] Regular penetration testing results available
  • [ ] Incident response plan documented
  • [ ] Data retention and deletion policies clear

Nice-to-Have

  • [ ] ISO 27001 certification
  • [ ] Compliance monitoring features for your environment
  • [ ] Single sign-on (SSO) support
  • [ ] Role-based access control within the platform

Balancing Security Review with Speed

Here’s the practical tension: a CMP evaluation that takes six months to clear security review costs you real money in unoptimized cloud spend. If your on-demand compute is running 40% above what automated commitment management would achieve, every month of delay is measurable waste.

Teams can approach this by:

  1. Starting with read-only access — onboard with visibility-only permissions first. This has minimal security footprint and lets you evaluate the platform’s data quality before granting write permissions.
  2. Using your existing vendor risk framework — don’t invent a new process for CMPs. Apply your standard third-party risk assessment with the specific CMP questions from this guide layered on top.
  3. Setting a time-box — commit to completing the security review in 2-3 weeks, not 2-3 months. If the vendor has SOC 2 Type II and provides clear IAM policies, most of the evaluation is verifying rather than discovering.
  4. Involving security early, not as a gate — bring your security team into the evaluation at the same time as the FinOps team, not after a champion has already committed.

Questions to Ask Every CMP Vendor

Close your evaluation with these direct questions. A credible vendor will answer all of them without hesitation:

  1. “What is the exact IAM policy you deploy in our account? Can we see the JSON?”
  2. “What is the minimum permission set required for basic functionality vs. full automation?”
  3. “How do we revoke your access? Is there any dependency on your cooperation?”
  4. “Where is our data stored? Which regions? Who can access it internally?”
  5. “Do you have a SOC 2 Type II report? When was the last audit period?”
  6. “What happens to our data if we cancel? What’s the retention and deletion timeline?”
  7. “Can we deploy with read-only access first and expand permissions later?”
  8. “How are API calls from your platform identified in our CloudTrail?”
  9. “Do you support external ID in cross-account roles?”
  10. “What’s your incident response process if you detect unauthorized access to our data?”

How nOps Handles Security and Compliance

We designed nOps cloud optimization platform for exactly this evaluation:

  • SOC 2 Type II compliant — independently audited with ongoing controls validation
  • Read-only access by default — visibility features require only billing and metadata read permissions. Write access is scoped exclusively to commitment purchases when automated management is enabled.
  • 5-minute onboarding with no infrastructure changes — no agents to install, no VPCs to configure, no code to deploy. A single CloudFormation stack creates the read-only role.
  • AWS Advanced Technology Partner — vetted through AWS’s partner security requirements
  • $4B+ in managed spend — security at scale across thousands of accounts

The platform is built so your security team can say “yes” quickly — because the permission scope is narrow, the audit trail is complete, and the compliance documentation is ready before you ask.

Start a free savings analysis — read-only access, no infrastructure changes, results in minutes.

FAQ

For AWS, the minimum is read access to Cost and Usage Reports (CUR) data plus basic account metadata. This can be achieved with a cross-account IAM role scoped to `ce:*` (Cost Explorer), `cur:*` (CUR), and `organizations:Describe*` actions. No EC2, S3, or other service write permissions should be required for cost visibility alone.
Type II. A Type I report confirms controls exist at a point in time. A Type II report confirms they’ve been operating effectively over a sustained period (typically 6-12 months). For a platform with ongoing access to your cloud accounts, you need evidence of sustained security, not a one-time snapshot.
Yes — but the write permissions must be scoped to specific actions. A commitment management platform might need `savingsplans:CreateSavingsPlan` and `ec2:PurchaseReservedInstancesOffering` without needing any other write permissions. The test isn’t “does it have write access” but “is the write access limited to exactly what the automation performs.”