When this is expected
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.
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.