Integrations / Cloud & infrastructure
Screenata + AWSHow do you continuously monitor AWS for SOC 2, ISO 27001, and HIPAA?
Quick answer
Yes, you can run a SOC 2, ISO 27001, or HIPAA compliant workload on AWS, but AWS itself is not the thing that gets audited. AWS certifies its own infrastructure layer and publishes its own attestation reports for it. Your account configuration, access control, encryption settings, and logging are yours to get right and yours to evidence. Screenata runs 144 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to AWS through a read-only IAM role and runs 144 native checks against your account configuration: IAM posture, S3 encryption, CloudTrail logging, security groups, and account password policy. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog, so one scan feeds every framework you run.
144 native checks · read-only · signed evidence
What it proves
AWS evidence, mapped to controls.
MFA enforcement on human identities, root account usage, access key age and rotation, least-privilege posture on roles and policies.
Proof that production access requires MFA and that credentials are rotated, the first thing an auditor samples.
Password length, complexity, reuse prevention, and expiry settings on the account.
Configuration snapshot showing the policy in force on the scan date.
Default encryption on buckets, public access blocks, and bucket policy exposure.
Per-bucket findings showing encryption at rest and no unintended public access.
Trail coverage across regions, log file validation, and delivery to durable storage.
Proof that administrative activity is recorded and tamper-evident, which monitoring controls depend on.
Open ingress on sensitive ports, wide CIDR ranges, and default security group usage.
Findings that production networks restrict inbound access to what the system description claims.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on AWS, and why each matters.
IAM Password Policy
Weak password rules let attackers guess or reuse credentials into the account. An auditor checks that minimum length, complexity, expiry, and reuse prevention are enforced on the account.
Root Account MFA
The root user can take any action in the account, so a stolen root password with no second factor means total compromise. An auditor verifies that MFA is registered on the root identity.
Unused IAM Access Keys
Active keys that are never used widen the attack surface, and a leaked key gives an attacker API access for data theft and unauthorized changes. An auditor checks that idle keys are deactivated or removed.
No Administrative Privileges on AWS-Managed Policies
A policy granting full administrative access lets any holder read, change, or delete any resource and disable logging. An auditor confirms that attached AWS-managed policies do not grant wildcard admin on all resources.
CloudTrail Multi-Region Enabled
If any region lacks a trail, an attacker can act in the unmonitored region with no audit record. An auditor verifies that API activity is logged across every region.
CloudTrail Log File Validation
Without log file validation, audit entries can be altered or deleted without detection. An auditor checks that CloudTrail produces signed digests so log integrity can be proven.
S3 Default Encryption
Buckets without default encryption may store objects in plaintext and let new uploads skip encryption. An auditor verifies that every bucket encrypts data at rest.
S3 Public Access Blocked
A public bucket lets anyone read or modify stored objects, which can expose data at scale. An auditor checks that public access blocks are set at the account and bucket level.
GuardDuty Enabled
Without threat detection, malicious activity in CloudTrail, VPC, and DNS data can go unnoticed. An auditor verifies that GuardDuty is enabled and healthy in each region.
SecurityHub Enabled
Without Security Hub, findings are fragmented and control checks do not run, so high-risk issues get missed. An auditor confirms Security Hub is active with at least one enabled standard.
AWS Config Recorder Enabled
Gaps in configuration recording create blind spots where resource changes go uncaptured. An auditor verifies the Config recorder is active and healthy in each region.
KMS Key Rotation Enabled
Long-lived key material raises the risk that an exposed key can decrypt stored data for a long time. An auditor checks that customer-managed KMS keys have automatic rotation enabled.
VPC Flow Logs Enabled
Without flow logs there is no visibility into network traffic, which prevents detection of unauthorized connections and exfiltration. An auditor verifies flow logs are enabled on the VPC.
No Root Access Keys
Root access keys grant unrestricted programmatic control and cannot be scoped, so their existence is a standing risk. An auditor confirms no access keys exist for the root account.
Security Group Open Ingress
A security group open to 0.0.0.0/0 on all ports invites scanning, remote exploitation, and lateral movement into the VPC. An auditor checks that inbound rules restrict access to required sources.
RDS No Public Access
An internet-reachable database invites brute-force attempts and unauthorized queries against sensitive data. An auditor verifies RDS instances are not publicly accessible.
RDS Storage Encryption
Without encryption at rest, database files, snapshots, and backups sit in plaintext for anyone who copies them. An auditor confirms RDS storage encryption is enabled.
S3 Access Logging
Without access logs, object reads, writes, and deletes go untracked, which hinders detection of unauthorized access. An auditor verifies server access logging is enabled on buckets.
EBS Default Encryption
Unencrypted volumes and snapshots can be copied or recovered to reveal raw data. An auditor checks that EBS default encryption is enabled for the account.
EC2 IMDSv2 Enforcement
Allowing IMDSv1 lets an SSRF flaw or compromised workload pull temporary IAM credentials from instance metadata. An auditor verifies instances require IMDSv2 with session tokens.
EBS Snapshots Encrypted
An unencrypted snapshot exposes a full disk image to anyone who can access or mis-share it. An auditor confirms EBS snapshots are encrypted at rest.
RDS Instance Automated Backups Enabled
Without automated backups there is no point-in-time recovery, so accidental deletes or destructive queries become unrecoverable. An auditor verifies the backup retention period meets the minimum.
RDS Instance Deletion Protection
Without deletion protection a single action can delete a production database and cause immediate loss of availability. An auditor checks that deletion protection is enabled on each instance.
S3 Bucket Versioning Enabled
Without versioning, a delete or overwrite removes the only copy, so compromised identities or buggy code can cause irrecoverable loss. An auditor verifies bucket versioning is enabled.
AWS Backup Plans Exist
With no backup plan, resources have no scheduled recovery points and restores may be impossible after corruption or deletion. An auditor confirms at least one backup plan is configured.
IAM Console Users Have MFA
A console user with no second factor is one phished password away from full access to production data in RDS, DynamoDB, and S3. An auditor verifies every IAM user with console access has an MFA device registered.
ELBv2 Listeners Enforce TLS 1.2+ Policy
TLS 1.0 and 1.1 carry known downgrade and cipher weaknesses that expose data in transit. An auditor checks that HTTPS listeners use a policy enforcing TLS 1.2 or higher.
IAM Access Keys Rotated Within 90 Days
Long-lived static keys are the most-leaked AWS credential and stay valid until someone rotates them. An auditor verifies active access keys are rotated within 90 days.
Drawn from Screenata’s AWS check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
BAA & attestation status
AWS offers a Business Associate Addendum, historically accepted through AWS Artifact, and designates a list of HIPAA-eligible services. PHI is expected to stay inside those eligible services. AWS also publishes its SOC 1, SOC 2, and SOC 3 reports through Artifact. Signing the BAA does not make your account compliant: encryption, access control, and logging configuration stay your responsibility, and you still have to show they operated.
What access does Screenata need to my AWS account?
A read-only IAM role that you create and control. Screenata assumes the role for scheduled scans and never receives write access. You can inspect exactly what the role permits before connecting, and revoke it at any time from your own AWS console.
Is the AWS integration enough for SOC 2?
It covers the infrastructure slice: access control, encryption, logging, and network boundary evidence from your AWS account. A full SOC 2 program also needs policies, HR and vendor evidence, and organizational controls, which come from your other connections and documents. About 70% of evidence across a typical program is collected automatically.
How often do the AWS checks run?
On a schedule, with weekly cloud scans as the default cadence. Each run produces fresh findings, and evidence freshness is tracked so anything approaching staleness gets flagged before an auditor sees it.
Can my auditor verify the AWS evidence independently?
Yes. Every finding is hashed with SHA-256, signed with RSA or ECDSA, and timestamped under RFC 3161. The evidence pack verifies with a free CLI outside Screenata, so the auditor does not have to trust a dashboard screenshot.
What are the steps to implement SOC 2 with AWS?
First, connect the account through a read-only IAM role so the scan can see your configuration without any write path. Second, let the first scan run and establish a baseline of where the account stands against the SOC 2 control set, instead of guessing which controls are already met. Third, fix what fails, which in most AWS accounts means enabling S3 default encryption, requiring MFA on the root account and on console users, turning on multi-region CloudTrail with log file validation, and closing security groups with open ingress. Fourth, let the scheduled scans collect the passing results as signed, timestamped evidence, so you build a history over the observation window rather than a single snapshot. Fifth, hand the evidence package to an independent auditor. The audit itself is a separate engagement you contract with a CPA firm; Screenata produces the evidence, it does not issue the report.
Is AWS HIPAA compliant?
No cloud provider is HIPAA compliant on its own, and AWS does not claim to be. AWS is HIPAA-eligible: it will sign a BAA and it designates which services you may place PHI into. Compliance is a property of how you configure and operate your workload on top of that. What makes the difference is encryption at rest and in transit, access control with MFA and least privilege, audit logging that captures administrative activity, and evidence that those controls actually operated over time rather than on the one day you looked.
Do auditors accept evidence Screenata collects from AWS?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting AWS, you know your real posture.
Related: Azure · Google Cloud · Kubernetes · GitHub