This article explains a common point of confusion: a test can sometimes show Pass even when the underlying evidence looks empty, null/false, or missing.
When this is expected
Some tests are designed to fail only when a specific configuration exists and is non-compliant. If that configuration does not exist in your environment, the test may pass (or be treated as not applicable) based on the control intent.
Example pattern:
- If you have configured a policy/setting in the source system, Secureframe validates it meets requirements.
- If you have not configured that policy/setting, the test may not have a concrete value to evaluate, and the result can still be Pass by design.
How to confirm if your result is correct
- Open the test and review what the test is actually checking.
- Validate in the source system whether the relevant setting/policy exists.
- Check evidence timing: if you just changed the source configuration, allow time for sync and rerun evaluation.
What to do if you think the test should fail
- Confirm the setting exists in the source system and is set to a non-compliant value.
- Confirm Secureframe is connected to the correct account/tenant and the integration is healthy.
- If the integration was recently connected, allow the initial sync to complete.
Comments
0 comments
Article is closed for comments.