This article brings together common customer questions and practical answers based on typical Secureframe workflows, compliance situations and unique tech stacks.

It is meant as quick reference material for day-to-day use of the product.

AWS general

Does AWS offer any Data Loss Prevention (DLP) tools or services?

• Yes. AWS offers native services that support Data Loss Prevention. For more information, please refer to AWS’s official documentation.

Does it matter which AWS region I'm in?

• No, it doesn’t matter which region you're in.

Does Secureframe support AWS CodeCommit for code repository tests?

• No, AWS CodeCommit is not currently supported as a direct integration within Secureframe. Since CodeCommit is being discontinued by AWS, Secureframe does not provide specific tests for it. Customers using CodeCommit should instead rely on the default non-integration code and change management tests to meet their compliance requirements.

How can a customer check what version of AWS Inspector they are on?

• In the URL, it will say either “inspector” or “inspector/v2.” Example: https://us-west-1.console.aws.amazon.com/inspector/v2/home?region=us-west-1#/

How do we handle multiple AWS accounts?

• If you need more than one integration for the same provider, run through the process fully for one, and once finished, start over again for the second.

How should customers handle required occasional AWS root logins near audit time?

• Occasional, justified root use is acceptable if properly documented, including:

  Purpose of login (e.g., billing issue)

  Who accessed it

  Supporting evidence in IAM logs

  Compensating controls (MFA enforced, access reviewed)

  You can:
  Add a note to the control record
  Track justification in Risk Register or governance logs
  Be prepared to explain to the auditor

  The test failing temporarily is not an audit blocker if the rationale is clear and documented.

If a customer has multiple AWS accounts connected under an org integration, can they configure different region settings per account?

• Region settings configured in the AWS integration apply globally to all accounts synced under that connection. If a customer needs to exclude specific regions for individual accounts (e.g., exclude ap-southeast-2 for one account and ap-southeast-1 for another), the recommended approach is to connect each account as a separate, individual integration rather than as a single org-level connection. This allows region settings to be configured independently per account.

Is AWS EC2 IMDSv2 a required test?

• IMDSv1 has a known SSRF vulnerability, and upgrading to IMDSv2 is recommended to mitigate this risk. If upgrading is not possible, it's important to track this vulnerability and assess its risk within your risk register.

We are based in India, are Board of Director bylaws fully applicable to us?

• The SOC 2 requirement aims for some level of independence from day-to-day controls. If your current structure meets that (e.g., leadership, investors, advisors), you are compliant. If the tests don't fit, you can disable them and provide a justification.

What does the interface look like with multiple AWS integrations?

• Here is an [example ](https://support.secureframe.com/hc/en-us/articles/24978391319571-Amazon-Web-Services-AWS)of what multiple AWS integrations look like in Secureframe, plus a slide out representing the parent/child relationship when those exist.

  You can also learn more about these relationships here. [https://support.secureframe.com/hc/en-us/articles/24978391319571-Amazon-Web-Services-AWS](https://support.secureframe.com/hc/en-us/articles/24978391319571-Amazon-Web-Services-AWS)

Why does the EC2 security group SMTP (port 25) test require restricting access to known IP addresses, and what should we do if our mail server needs port 25 open to the internet?

• This test is designed to enforce least-privilege network access and reduce the risk of unauthorized or abusive SMTP traffic from EC2 instances. In most modern architectures, EC2 instances should not send or receive email directly over port 25 to or from the public internet. Instead, outbound email is typically routed through a managed SMTP relay or email service, or restricted to internal systems with known IP ranges.

  Because of this, unrestricted access to port 25 (for example, 0.0.0.0/0) is treated as a security risk and will cause the test to fail. To pass the test, organizations can restrict port 25 to known IP addresses, remove the rule entirely if SMTP is not required, or route email through an SMTP relay and limit access accordingly.

  If your business architecture legitimately requires port 25 to be open to all IPs (such as a public-facing mail server), the test result can be left failing and supported with a documented business justification explaining the need and any compensating controls. Auditors commonly accept this when the rationale is clearly documented.

Why does Secureframe still show deactivated AWS IAM users as “Active”?

• This is expected behavior today and is due to a limitation in the AWS IAM APIs.

  AWS does not provide a single “active” or “inactive” status for IAM users. Instead, Secureframe relies on the data AWS returns during integration syncs. When AWS does not explicitly indicate a user’s status, Secureframe defaults the user to Active.

  Because of this, even if an IAM user has been effectively deactivated in AWS—such as having no console login profile and all access keys disabled—Secureframe may still display the user as Active. These records are intentionally retained to support audit history, evidence tracking, and historical accountability.

  Why this happens

  AWS IAM does not expose an authoritative active/inactive flag

  When user status is unknown, Secureframe marks the account as Active

  Deleted or deactivated users may still appear for audit traceability

  What you can do today

  Verify directly in AWS that the IAM user has no login profile and no active access keys (or confirm the user has been deleted)

  Treat the Secureframe record as historical, not an indicator of current access

  Upload evidence (such as screenshots or exports from AWS) showing the user is inactive or removed to satisfy audit requirements

  Archive or suppress the entry in Secureframe to reduce reporting noise (contact Support for assistance)

  Work with your Customer Success Manager if you’d like guidance on the best way to document this evidence in the platform

  Future improvements

  We’re actively working on enhancements to better reflect a user’s true status at the source. In future updates, Secureframe will more clearly distinguish these scenarios—for example, showing users with no login profile and no active keys as “Inactive at source” rather than Active.

  Until then, marking these users as inactive through uploaded evidence is the recommended approach for audits and reporting.

Do we need to use CloudTrail?

• AWS CloudTrail is not a requirement, but logging and monitoring throughout your environment are. CloudTrail is the most common tool if using AWS, but other tools can be used if CloudTrail is not preferred.

Is AWS CloudTrail required?

• AWS CloudTrail is not a strict requirement, but logging and monitoring are mandatory. CloudTrail can be disabled if you're using alternative logging tools like AWS CloudWatch or Datadog.

S3 bucket uses object versioning. Some do, others don’t. Do we have to version everything?

• No, but if you have many, you don’t want to ignore all of them. If buckets are configured for a specific situation, you can ignore them. AWS allows different configurations to cater to different environments. The goal is to ensure you are monitoring and controlling traffic appropriately.

We have a few S3 buckets which we have made publicly readable, because they store ONLY web-assets (images, stylesheets, static HTML, fonts, etc.) for our applications, but they are still failing?

• Make the bucket private and then use a CloudFront distribution in front of it (this is the recommended AWS best practice).

Is GuardDuty required for customers who use AWS?

• GuardDuty is the recommended AWS security tool for threat detection. If cost is a concern, some auditors may allow alternative solutions like WAFs, though GuardDuty is the preferred option.

Using CloudFormation, can a client tag cloud resources out of scope on AWS?

• No, cloud resources cannot be tagged out of scope directly via CloudFormation. They can only be marked as out of scope within Secureframe.

What does the Systems Manager Agent Parameter encryption test in AWS evaluate?

• This test checks that your AWS Systems Manager (SSM) parameters are configured to enable encryption. SSM Parameter Store allows you to store configuration data and secrets (such as passwords, API keys, and license codes) as parameters. Encrypting these parameters using AWS KMS (Key Management Service) ensures that sensitive data is protected at rest. This test verifies that encryption is enabled on your SSM parameters to help meet security and compliance requirements.

What should I do if GuardDuty detectors are not found in all regions for AWS integration?

• If GuardDuty detectors are not found in all specified regions when configuring your AWS integration settings, ensure that GuardDuty is enabled in all regions included in the integration setting. Once your region settings have been updated, allow the integration sync to complete for accurate test results.

What log types should be enabled for OpenSearch Service logging?

• For OpenSearch Service logging, the following log types typically need to be enabled: Audit Logs (to track user activity and API calls), Error Logs (to capture system errors and failures), Slow Logs (to monitor slow queries and operations), and Application Logs (if the application writes custom logs to OpenSearch).