# Ensure SNS topics have policy set as Public

- Source: https://support.icompaas.com/support/solutions/articles/62000236249-ensure-sns-topics-have-policy-set-as-public
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Checks New Version](https://support.icompaas.com/support/solutions/62000112673) › [AWS New Checks](https://support.icompaas.com/support/solutions/folders/62000169206)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:**  
Level 1  
  

**Description:**  
This control ensures that Amazon Simple Notification Service (SNS) topics are not publicly accessible through overly permissive access policies. SNS topic access policies define who can publish or subscribe to topics. If a policy allows unrestricted (`Principal: "*"`) access, anyone on the internet could publish or subscribe to messages, leading to data leakage, spam messages, or unauthorized actions within your AWS environment.  
  

**Rationale:**  
SNS topics often contain sensitive operational, monitoring, or alerting data. Allowing public access exposes the service to misuse, data injection attacks, or denial-of-service attempts. Restricting SNS topic access policies to specific AWS accounts, IAM users, or roles helps enforce the **principle of least privilege** and ensures that only trusted entities can interact with your topics.  
  

**Impact:**  
**Positive Impact:**

-   Prevents unauthorized entities from publishing or subscribing to sensitive SNS topics.
    
-   Reduces the risk of data loss or message tampering.
    
-   Ensures compliance with security standards such as CIS, ISO 27001, and SOC 2.  
    **Negative Impact:**
    
-   Overly restrictive permissions may block legitimate cross-account communications if not properly configured.  
      
    

**Default Value:**  
By default, SNS topic access policies are private and allow access only to the topic owner. Public access must be explicitly configured.  
  

**Pre-Requisite:**

-   IAM permissions required: sns:ListTopics, sns:GetTopicAttributes, sns:SetTopicAttributes.
    
-   Awareness of all SNS topics and their usage patterns (e.g., internal notifications, cross-account alerts).  
      
    

**Test Plan**   
**Using AWS Console:**

1.  Sign in to the AWS Management Console.
    
2.  Navigate to **Amazon SNS → Topics**.
    
3.  Select a topic and go to the **Access policy** section under the **Permissions** tab.
    
4.  Review the JSON policy for `"Principal": "*"`.
    
5.  If the `"Effect": "Allow"` is combined with `"Principal": "*"`, this indicates public access (❌ Non-compliant).
    
6.  Ensure that the policy restricts access to specific AWS accounts, IAM roles, or services that require it (✅ Compliant).  
      
    

**Implementation Plan**   
**Using AWS Console:**

1.  Navigate to **Amazon SNS → Topics**.
    
2.  Select the topic you wish to secure.
    
3.  Go to the **Access policy** under the **Permissions** tab.
    
4.  Click **Edit** to modify the policy.
    
5.  Remove any statements granting `"Principal": "*"`.
    
6.  Replace them with specific principals, such as IAM roles, users, or AWS account IDs that legitimately require access.`   `
    

If this configuration is found, it must be remediated immediately.  
  

**Backout Plan:**

1.  If legitimate external integrations were disrupted by access restrictions, temporarily re-add required accounts or IAM roles to the access policy.
    
2.  Review and confirm external dependencies before reapplying restrictions.
    
3.  Document business justification for any cross-account access and include it in your access review logs.  
      
    

**References:**

-   Amazon SNS Access Policy Documentation
    
-   AWS IAM Policy Best Practices
    
-   CIS AWS Foundations Benchmark v2.0.0 – Control 3.26
    
-   AWS Security Best Practices

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.