SOC 2 Exceptions: When a Laptop Falls Out of Compliance

In month five of a Type 2 observation period, one engineer's laptop stops reporting. The disk is still encrypted, probably. The screen lock was set, probably. Nobody can show either for the six weeks it was dark.

That gap is where most device findings come from. Not from a laptop that was never configured, but from one that was right on day one and unprovable on day ninety.

What happens when a laptop falls out of compliance during a SOC 2 Type 2 period?

The auditor records an exception: a test that did not come back clean. It is a factual finding about one control and one period, not a verdict on the whole company. Whether it changes the report's opinion depends on how many exceptions there are and how widely they spread.

Sensiba's explainer on audit findings defines exceptions as "instances where a company's practices do not fully comply with the established criteria." It adds that minor exceptions are unlikely to change the overall opinion and that exceptions are common in first-time Type 2 audits.

For devices, the common shape is simple. The policy says every in-scope laptop is encrypted, locked, patched and protected. The sample pulls a laptop, and the record for it is missing, stale or contradicts the policy.

Can you actually fail a SOC 2 audit over one device?

No. An attestation engagement produces a report, not a pass or fail mark. A-LIGN's article on whether you can fail a SOC 2 examination makes this point and says a modified opinion is most easily identified through "exceptions noted in the test of controls performed."

The same article says that when an exception appears, "additional samples are selected" to check whether the control works. One bad laptop therefore rarely stays one bad laptop. A second look at the fleet is the real risk, because it turns an isolated lapse into a pattern.

It also describes when the opinion must change. If a key control supporting a control objective is not working, the opinion "must be modified" to disclose that. Auditors weigh how many exceptions there are, how pervasive they are, and how central the control is.

Outcome	What it means for devices
Unqualified opinion	Controls operated, or exceptions were minor and isolated
Qualified opinion	A specific control area, such as device encryption, did not meet the criteria
Adverse opinion	Problems are pervasive across the system or most objectives

Treat the table as a map of the vocabulary. Your auditor decides which row applies.

Why does one drifting laptop turn into a sample failure?

Because the evidence a device produces is usually a snapshot, and a Type 2 test asks about a span. If your proof of encryption is a screenshot taken at onboarding, it says nothing about month five.

Three patterns create most device exceptions:

• A silent device. The laptop stopped reporting, so there is no reading for the gap. Absence of data is not evidence of compliance.
• A late fix. The reading shows the setting was off, then on again. The control did fail for that interval, even though it was repaired.
• An undocumented decision. A person knew about the drift and chose to wait. No record shows the choice, who made it, or when.

The first is the one teams underestimate. Our post on reporting devices you can't verify argues that "unknown" has to be a first-class state, because collapsing it into "pass" is how a dark laptop ends up in the compliant column.

What should you do the day you find the drift?

Treat it as a fact to document before it is a problem to hide. OneUptime's guidance on a control failing during a Type II period is blunt about the order of operations. Preserve the original evidence before anything changes, record when and how the issue was found, and establish the full affected population.

It also lists what never to do: "Never backdate an approval, edit a screenshot, remove failed items from the population." A device record that was quietly cleaned up is worse than an honest exception, because auditors test for exactly that.

A workable same-day sequence for a laptop:

1. Capture the current device reading and the last good reading, with timestamps.
2. Note when the deviation began and when it was discovered. Keep the two dates separate.
3. Identify every other device with the same configuration, not just the one you found.
4. Fix the root cause, whether that is an enrollment failure, a broken sensor or a policy gap.
5. Tell the auditor. The same source advises that you "notify the engagement team when management identifies a potentially relevant matter."

Does fixing the laptop erase the exception?

No. OneUptime puts it plainly: "Remediation can reduce current and future risk but does not make the historical deviation disappear." The interval when the control was off stays in the record.

What remediation changes is the story around it. A finding with a dated cause, a defined affected scope and a verified fix reads as a control that detected its own failure. A finding with none of those reads as a control nobody was watching.

This is also why a policy edit is not a fix. Rewriting the encryption standard shows intent. Showing that the affected laptop now reports encrypted, and has done so continuously since, shows the control operating again. Our guide to patch management evidence auditors test walks through the same distinction for update windows.

How should the management response read?

Short, factual and specific. Keiter's guidance on management responses to testing exceptions says management responses appear in Section V of the report, are unaudited, but are read closely by auditors and readers. It advises responding to each finding, with "plans to address immediate items discovered by the auditor" and the root cause, meaning "the causes that gave rise to the exception."

For a device exception, a good response covers four things: what happened to which class of device, how many devices were affected, what was fixed and on what date, and what now detects the same drift sooner. Keep completed remediation separate from planned work, and do not claim the auditor validated a fix unless the report says so.

How do you keep a drift from becoming an exception at all?

You cannot prevent every drift. Laptops sleep, travel, get reimaged and lose enrollment. You can shorten the window between drift and detection, and you can make the record continuous so the window is visible and small.

The device record that does this has four properties:

• Continuous readings. Posture is collected on a schedule, so a gap is itself a datapoint instead of a surprise at sampling time.
• Stable identifiers. Each reading is tied to a serial number and an owner, so a population can be rebuilt without a manual hunt. Our device inventory guide covers keeping that register honest.
• Honest unknowns. A device that stopped reporting shows as unknown, not as its last good state.
• Retained history. Readings are kept for the whole period, so you can show the interval, the fix and the continuous run since.

The same logic applies at the ends of a laptop's life. A device that left the company without a recorded wipe is a drift that no sensor can catch after the fact, which is why offboarding evidence and disposal evidence need their own records.

SAUTERA scores device trust from live sensor readings and keeps the history, so the date a laptop drifted and the date it recovered are both on the record. Remediation stays human-approved.

Key takeaways

• An exception is a test-level finding about one control and one period. It is not a pass or fail mark on the audit.
• Additional samples follow an exception, so one device can become a fleet question quickly.
• Preserve evidence first, document the deviation and remediation dates separately, and tell the auditor.
• Remediation does not erase the historical deviation, but it changes how the finding reads.
• Continuous device readings, stable identifiers and an honest "unknown" state shrink the window in which a drift can hide.

Want a dated record of every laptop's posture before the next sample? Start free with 10 devices, 30 days and no card.