Security & Compliance
How we protect your AWS environment
Cloudvisor operates as a Managed Service Provider (MSP) for AWS. Everything we do is built around one principle: you own your AWS environment, always — we never do.
- You retain full ownership of your AWS accounts, root credentials, and all data in them.
- We access your environment only through scoped, customer-deployed IAM roles — never through IAM users or shared credentials.
- Every change to your infrastructure requires your explicit approval before we implement it.
- Security findings go through a formal, documented incident response process.
Data ownership
Your AWS accounts, root credentials, and workload data are yours — we never take ownership of them, during or after an engagement.
- Root account access stays with you. Managed accounts use your own corporate email as the AWS root user; we never hold, store, or request root credentials.
- Your data is never co-hosted on our systems. Our internal tooling is fully separate from your AWS accounts.
- Decisions about data sensitivity, retention, and deletion are yours to make — we advise, we don’t decide unilaterally.
- When an engagement ends, you revoke our access. We don’t retain your data beyond what’s needed for final reporting.
Access control
- Cross-account access is granted through a dedicated, customer-deployed, revocable IAM role, provisioned via a Cloudvisor-provided CloudFormation template. It’s fully within your control and revocable at any time.
- Our engineers access your account by assuming that role — we never create direct IAM users in your environment.
- Every engineer’s access requires mandatory multi-factor authentication (MFA). No MFA, no access — full stop.
- Monitoring access uses AWS IAM Identity Center (SSO); no standing AWS console credentials are issued to our engineers.
- A read-only role is available for audits and analysis, deployed and revocable the same way.
- You can revoke all Cloudvisor access at any time by deleting the CloudFormation stack — no dependency prevents immediate, full revocation.
Change management
- Every change to your infrastructure requires your explicit approval before we implement it.
We identify, document, and communicate proposed changes; you approve them. - Change proposals are communicated through a dedicated Slack channel or email, depending on urgency.
- During a critical (P1) incident, we may act immediately to contain impact where a delay would make things worse — you’re notified simultaneously and retroactive approval is sought.
- Every implemented change is logged and summarized in your monthly infrastructure report.
Security monitoring
- Monitoring is deployed across dozens of AWS services per account, with automated alert routing to your dedicated Slack channel.
- Amazon GuardDuty is enabled on every managed account; findings are triaged by our engineering team under our incident response process.
- AWS Config, with a tailored Conformance Pack, enforces configuration compliance per account.
- AWS Security Hub aggregates findings from GuardDuty, Config, and Inspector into a single view.
- Remediation is proposed and implemented only with your approval, except for emergency containment actions.
- Every active finding is tracked to resolution and summarized in your monthly report.
Incident response
Incidents are classified by severity, with response times to match:
- Critical (P1): 30-minute response. We investigate immediately, propose and implement containment, notify you at the same time, and deliver a post-incident summary.
- High (P2): 2-hour response. Root cause analysis, with remediation proposed and implemented on your approval.
- Low/Informational (P3): Logged and included in your next monthly report.
- Signals like exposed credentials or unusual API activity are treated as P1 by default whenever root accounts or IAM keys may be involved — regardless of the automated severity score.
- Every significant security event gets a post-incident review, with findings and corrective actions documented and shared with you.
Credential & Secret management
- Secrets, API keys, passwords, and tokens are never committed to version control.
- Pipeline secrets are isolated per environment (development, staging, production).
- We prefer OpenID Connect (OIDC) for CI/CD access to AWS over long-lived access keys wherever it’s supported.
- Infrastructure-as-code is automatically scanned for secrets and misconfigurations before deployment.
- Any exposed credential is treated as a P1 incident: disabled or rotated immediately, with customer notification and root cause analysis.
Personnel security
- Every engineer undergoes a background check before being granted access to customer environments.
- Every engineer signs an NDA covering customer data before joining the team.
- Access is need-to-access and least-privilege — granted only for the duration of active engagement.
- Access is reviewed periodically, and revoked promptly when someone changes roles or leaves.
GDPR
We’re GDPR compliant. When a client relationship ends, identifying information is removed as part of offboarding.