Background Check Evidence: How Policy and Evidence Tests Work

A compliance lead recently asked our support team a question we hear often. Their policies page showed a tests column with values like 0/3, and the background check requirement had more than one test attached to it. Were those tests something they had to build? Did SecureSlate run them? And how could they see what each test wanted so they could map their evidence to it?

It's a good question, because the answer explains how auditors think about background checks. Having a policy isn't enough. You also have to show that you followed it.

This guide covers:

• Why a background check requirement can carry both a policy test and an evidence test
• What makes each test pass
• How manual and automated tests differ
• How to keep employees acknowledging the current version of your screening policy

If you're new to the topic, start with our guide to SOC 2 background check requirements, which covers what to screen for and how to plan the process.

---

Key takeaways

• A single background check requirement is usually tested twice: once to confirm the policy exists and is approved, and once to confirm checks were actually completed.
• The policy test passes when the required policy is approved. The evidence test passes when supporting evidence is uploaded and meets the test's requirements.
• Tests can be manual or automated. Automated results depend on your integrations and the specific requirements of each test.
• Every test includes "How to Fix" instructions, so you don't need to guess what evidence an auditor expects.
• When you re-approve a policy, you can choose to notify employees, and you can track who has accepted the new version from the employee page.

Why one requirement has two tests

Auditors evaluate controls on two questions: is the control designed properly, and is it operating? For background checks, that splits naturally into two tests.

Test	What it verifies	What makes it pass
Policy test	A background check (personnel screening) policy exists and has been approved	Approving the required policy in SecureSlate
Evidence test	Background checks were completed for in-scope personnel	Uploading supporting evidence that meets the test's requirements

The policy test proves intent. It shows your organization has defined who gets screened, when, and by whom. The evidence test proves execution. It shows the checks happened.

This is why a policy can be approved and the requirement still looks incomplete. A 0/3 or 1/2 in the tests column doesn't mean your policy is wrong. It means some of the tests tied to that requirement are still waiting on something, often evidence.

Manual and automated tests

You don't need to create these tests yourself. They come with the framework requirements in SecureSlate. What varies is how each one gets its result.

• Automated tests check a condition for you. Their outcome depends on the integration involved and the specific requirements of the test. A policy test is a simple example: once the policy is approved, the test is marked as passing.
• Manual tests rely on evidence you provide. Background check results usually come from an outside screening provider or your HR team, so the evidence test is often manual. You upload the files, and the test passes once all of its requirements are met.

Either way, the status updates in real time, so you can see progress as your team works through the list.

Mapping your evidence to each test

The quickest way to map evidence is to open each test and follow its How to Fix instructions. Each test spells out what it needs, so you can match your existing records to it instead of guessing.

For a background check evidence test, useful evidence typically includes:

• Completion records or reports from your screening provider for new hires in the audit period
• A list of in-scope employees and contractors, with hire dates, so the auditor can sample from it
• Proof that checks happened before access was granted, or within the timeframe your policy defines
• Records of any exceptions, such as a delayed check, and who approved them

A few practical tips:

1. Redact what the auditor doesn't need. Auditors usually need proof that a check was completed, not the full contents of the report. Keep sensitive personal details out of uploads unless the test calls for them.
2. Match your policy to your practice. If your policy says checks run before day one, your evidence should show that. Gaps between the policy and the evidence are a common audit finding.
3. Upload as you hire. Adding evidence when each check completes is far easier than collecting a year of records the week before fieldwork.

For more on preparing records for auditors, see our guide to handling audit evidence requests.

Keeping employees on the current policy

Background check policies change. You might add a new role to the screening scope, change providers, or update timing rules. When that happens, employees should acknowledge the new version, and you need a record that they did.

The same customer asked how this works for annual reviews. Here's the flow in SecureSlate:

1. Version and re-approve the policy. Upload the new version in the policies section and approve it. Version details live in the policies section.
2. Choose whether to notify employees. When you approve the new version, you'll be asked whether employees need to accept it. If you confirm, they're notified by email.
3. Employees accept the policy. When employees sign in, they see the policies they haven't completed yet and can review and accept them.
4. Track acceptance. Open the employee page and select an employee to see their acceptance status. You can also export the logs from the employee page to share with an auditor.

Assigning the right policies to the right people

Not every policy applies to every employee. In SecureSlate, each employee belongs to one group, and each group has its own checklist of policies. The same policy can appear in several checklists, so a background check policy can be assigned to engineering, sales, and operations while role-specific policies go only where they apply.

One note on terminology: the onboarding status shown for employees refers to onboarding into SecureSlate, not your company's HR onboarding. It shows real-time progress and changes to completed once the employee finishes.

Background check evidence checklist

Use this before your audit window opens:

• Background check policy written, reviewed, and approved
• Screening scope defined (employees, contractors, specific roles)
• Policy assigned to every relevant employee group checklist
• Employees have accepted the current policy version
• Completion evidence uploaded for in-scope hires in the audit period
• Exceptions documented with approvals
• Each related test opened and its How to Fix steps completed
• Employee acceptance logs exported and ready for the auditor

FAQ

Why is my background check requirement not passing after I approved the policy?

Approving the policy satisfies the policy test only. Most background check requirements also have an evidence test that needs proof that checks were completed. Open the remaining tests and follow their How to Fix steps.

Do I have to set up the tests myself?

No. Tests come with the framework requirements. Some are automated and some need you to upload evidence, but you don't build them from scratch.

What evidence do auditors expect for background checks?

Typically, proof that checks were completed for in-scope personnel within the timeframe your policy defines, plus a population list the auditor can sample from. Requirements vary by auditor and framework, so confirm with yours.

How do employees find out about a new policy version?

When you approve a new version and choose to require acceptance, employees are notified by email. They'll see the incomplete policy when they sign in.

Can I see who has accepted the latest version of a policy?

Yes. Open the employee page and select an employee to view their status, or export the logs from the employee page for a full record.

Disclaimer (legal note)

This article is for general informational purposes only and is not legal, audit, employment, or professional advice. Background check rules vary by jurisdiction and role, and screening practices must follow applicable employment and privacy laws. Consult qualified advisors and your auditor for requirements specific to your organization. Product capabilities may change over time.