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.
Frequently Asked Questions (FAQ)
Can an integration password test pass with no evidence if we use SSO or Google Sign-In?
Yes, that can be expected. If passwords are managed by your identity provider and not in the connected system (for example Cloudflare), the integration may have no password policy to evaluate.
Some tests pass when the setting does not exist, so you can see Pass with little or no visible evidence in Secureframe. Confirm in the source system whether a local password policy applies, or whether authentication is handled only by SSO / Google Sign-In.
For Upload vs Integration tracking fields (including why Last Uploaded can be blank), see FAQs: Test uploads, tracking, and audit Testing tab.