How to Prove Screen Lock on Every Laptop to a SOC 2 Auditor

Screen lock looks like the easiest control in a SOC 2 audit. Then the auditor asks what "locked" means, and the answer turns out to depend on three settings, two operating systems and a policy sentence nobody wrote carefully.

How do you prove screen lock on every laptop to a SOC 2 auditor?

Define "locked" as a testable condition, read that condition from each laptop on a schedule, and keep the dated readings for the full audit period. The proof is a per-device record that matches your written policy, not a screenshot of one settings page.

The three parts matter in that order. A vague definition cannot be tested. A test run once cannot show the control operated all year. Agency's SOC 2 evidence guide puts the timing rule bluntly: evidence "must be collected contemporaneously, meaning at the time the control was operating," and you "cannot recreate or backfill evidence for a period that has already passed."

What counts as "locked" in a SOC 2 audit?

SOC 2 publishes no screen lock number. The test is your own policy, so the policy sentence has to be precise enough to check. "Laptops lock when idle" is not. A checkable version names an idle time and says a password is required to resume.

Tooling vendors do commit to a number for their own tests. Drata's screensaver lock test fails a computer that does not require a password "60 seconds or less after the machine has been idle for at least 15 minutes." That is one vendor's threshold, not a SOC 2 rule. Choose a value that fits your risk, write it down, and measure against exactly that.

Notice the two clauses in the Drata wording. A condition has a trigger (idle time) and a consequence (a password is demanded). A screen that dims and then resumes on a keypress meets the first and fails the second. Evidence that records only "screensaver enabled" cannot tell those apart.

Why does the default setting not count as a control?

Because on a standard Windows laptop the default is off. Microsoft documents the Interactive logon: Machine inactivity limit policy and lists the client computer default as disabled. A value of zero or blank means a sign-in session is never locked after inactivity.

Two more details from the same page change how you gather evidence:

• The lock has dependencies. The page says the session locks by invoking the screen saver, which should be active on the machine. A policy value set without the screen saver behind it may not behave the way the number suggests.
• It is not instant. The page states a restart is required for changes to take effect. A policy assigned this morning is not a policy in effect this morning.

The lesson for evidence: "the policy was pushed" and "the laptop locks" are different claims. Read the effective state from the device, not the intent from the console.

What can go wrong between the policy and the laptop?

Most failures sit in the gap between a setting and the behavior it was meant to produce. Four are worth testing for before fieldwork.

1. Display sleep versus lock. The screen goes dark after a few minutes, but resuming does not ask for a password.
2. Grace periods. A short window after lock where the password is waived, sometimes set generously for convenience.
3. Local overrides. A user, or a script, changes a setting the management profile was supposed to hold.
4. Exempt devices. Shared kiosks, conference-room machines and lab hardware that were deliberately excluded and never written down as exceptions.

None of these shows up if you check only that a profile exists. Each shows up if you read the effective values. Microsoft's own page frames the setting as a trade-off with productivity and device location, which is why exemptions exist. The mistake is leaving them unrecorded.

How should you document the exceptions?

Treat every exemption as a record with an owner, a reason, a compensating control and a review date. An auditor accepts a kiosk that does not lock if you can show why and what covers the risk instead. They do not accept a kiosk they discover.

The same applies to personal laptops. Drata's BYOD guidance notes that when the company doesn't own the device, it can't enforce configurations, and lists three routes to evidence: enrolling the device in an MDM, using the vendor's own software, or having employees submit screenshots. It adds that privacy and legal rules may limit what you can require, so involve HR and Legal first, and that whether alternative controls are accepted "is up to your auditor to decide." Settle that question before the window opens.

What should a per-device screen lock record contain?

Enough that an auditor can sample it and not come back with a question. Five fields do it:

1. A stable device identifier, such as a serial number.
2. The idle time, the grace period and whether a password is required on resume.
3. The source of the reading: the device itself, a management tool, or a manual upload.
4. A capture timestamp.
5. The owner, so a failing laptop has someone to go to.

The source field earns its place. A value the device reported about itself carries more weight than a screenshot an employee sent, and a record that says which one it is lets the auditor decide how far to trust it. We use the same shape for disk encryption and for EDR coverage, so one evidence pipeline can serve all three.

How do you show the control held for the whole period?

Keep the readings, not just the latest one. A console that shows today's compliance answers a different question than the auditor's. Hexnode's guide observes that a compliance view "recomputes the current state" and that many platforms keep little history or only a rolling window. If your tool works that way, export on a schedule and store the files somewhere that does not expire.

Then build the exceptions trail. When a laptop's lock setting drifts, you want a dated detection, an owner, a fix and a fix date. A year with no exceptions at all invites the question of whether anything was looking. A few well-handled exceptions are the stronger story.

Finally, say how you know the list is complete. Evidence about the laptops you can see says nothing about the ones you cannot. That is the subject of our piece on what auditors check in a SOC 2 device inventory. A device that has not reported should appear as unknown, never as a pass, as we argued in unknown is an answer.

What should you do before the audit window opens?

A short list for the week before:

1. Rewrite the policy sentence so it names an idle time and a password on resume.
2. Read the effective lock values from a sample of laptops and compare them to the policy.
3. List every exempt device with its reason and compensating control.
4. Start scheduled exports now, because past periods cannot be rebuilt.
5. Agree with your auditor on the evidence format for managed and unmanaged devices.

If you also want the monitoring side covered, observe versus enforce explains what to ask a controls-monitoring vendor.

Key takeaway

The hard part of screen lock evidence is the definition, not the setting. Write a policy that can be tested, read the effective state from each device, record exceptions before anyone finds them, and keep dated readings for the whole period. That combination holds up when an auditor samples it.

See how SAUTERA scores device evidence from live telemetry, including the honest "unknown" — start free with 10 devices for 30 days, no card.