Teams hesitate to deploy preventive policies because they don't know the impact. Will it block legitimate workflows? Will production deployments fail? The fear of breaking things keeps policies stuck in draft mode. **Turbot Guardrails provides an interactive policy [simulator](https://turbot.com/guardrails/docs/prevention/simulator)** that lets you test policies before deploying them to production. Work with your existing policies or create new ones. Duplicate policies to test modifications. Change where they're attached in your organizational hierarchy. Test how they perform by creating mock events or uploading real CloudTrail data from your environment. Security teams can iterate through variations and validate behavior in a safe environment without any production risk. ## Visualize Your Organization and Policies The [simulator](https://turbot.com/guardrails/docs/prevention/simulator) loads your cloud organization structure and displays it as an [interactive graph](https://turbot.com/guardrails/docs/prevention/accounts/visualize). In this example, we see an AWS Organization with its Organizational Units, accounts, and Service Control Policies attached at each level. The inheritance hierarchy shows how policies flow down through OUs to accounts.

Organization visualization showing OUs, accounts, and attached SCPs

Interactive organization view with policies attached at different levels

Expand and collapse OUs, search for specific accounts or policies, and see where each policy is attached. The visual layout makes it clear which accounts inherit which policies and what the blast radius is for any change. ## Test Events Against Your Policies Create a mock event to test how your policies evaluate it. Select "EC2 RunInstances" as the action, `eu-west-1` as the region, and `goliath-commbank-fintech` as the target account. Run the evaluation.

Bring CloudTrail events or create mock events through the SCP Simulator

Edit mock events to simulate how your SCPs perform

The simulator shows the event passes through several SCPs in the path but gets blocked by two different Service Control Policies. This overlap is helpful to see. You have duplicate region restriction policies enforcing the same control at different levels. The evaluation detail shows exactly which statements in each policy caused the denial.

Event evaluation showing it blocked by two SCPs

The event passes through some SCPs but gets blocked by two different policies

## Compare Multiple Scenarios Duplicate the event to test another region, `eu-west-2`.

Quickly duplicate and modify events to test different scenarios

Now you have two events to compare. Flip between them and run evaluations. Both are blocked by the same two SCPs.

Quickly test variations by duplicating and modifying events

This quick comparison shows how to test multiple scenarios without recreating events from scratch. You see immediately that both European regions are being blocked. ## Modify Policies to Test Changes To test how you can adjust the SCPs to allow `eu-west-1` while keeping other regions restricted, duplicate one of the existing SCPs. Add `eu-west-1` to the allowed regions list in your modified SCP version. Run the evaluation again.

Modified SCP allows the event but still blocked by other policy

Duplicate and modify an SCP to test the impact of changes

The evaluation shows your modified SCP now allows the event, but it's still blocked by the other existing SCP. You see exactly where the remaining restriction comes from. This shows the value of testing modifications before deploying them. You thought changing one policy would fix it, but the overlap means you need to address both.

Your modified SCP allows the action, but the other policy still blocks it

## Disable Policies for What-If Testing Disable the two SCPs that are blocking the event. Run the evaluation for the `eu-west-1` event. It now passes completely through all policies.

Event passes with blocking SCPs disabled

With the blocking SCPs disabled, the event is fully allowed

Click back to the `eu-west-2` event and run it. Still blocked. Your modified SCP allowing `eu-west-1` doesn't affect `eu-west-2`. You understand exactly what each policy variation permits and what it blocks. Every test happens in simulation without affecting your live environment.

Quickly test another event to prove it's still blocking the other region

## Change Policy Positioning Take your modified SCP and change its attachment point from an OU to the Organization Root. The visualization updates to show all accounts now inherit this policy.

Policy attached to Root showing broader inheritance

Attaching to Root expands the policy's scope across all accounts

Test events across different accounts to validate the broader scope works as intended. You see the blast radius of your change before deploying it. When you're confident the policy behaves correctly, you can deploy it to production starting with test accounts and expanding gradually. ## See it in action Watch this demo to see how to test preventive policies against activity data before deployment.

## Deploy with Confidence The simulator transforms policy deployment from guesswork into informed decision-making. You can test events, modify policies, disable controls, and change attachment points to see exactly what happens before deploying to production. Every test is safe. You iterate through variations, discover overlaps, and understand blast radius without any risk to live environments. The simulator is included in Turbot Guardrails PSPM platform. Interested in running this in your environment? [Connect with us](https://turbot.com/start) to get your free preventive security posture assessment and start simulating changes to your organization's policies.

Simulate and test AWS SCPs