SOC 2 and your camera fleet: what counts as evidence

Camera evidence counts for SOC 2 when it covers the entire observation period, exists per device, was generated as events happened rather than assembled afterward, and comes from a population the auditor can accept as complete. That last property is the one most teams have never thought about, and it is the reason a folder of screenshots gets rejected while a boring log file passes. This post explains where cameras land in the Trust Services Criteria, what a SOC 2 auditor is actually testing when they ask about physical security, and what shape your camera records need to have before the fieldwork starts.

Where cameras land in the Trust Services Criteria

SOC 2 has no camera requirement. It has criteria about restricting physical access and detecting anomalies, and cameras are how most organizations satisfy them. The criteria that pull a camera fleet into scope are these:

Criterion	What it asks	How cameras get pulled in
CC6.4	Physical access to facilities and protected assets is restricted to authorized personnel	Cameras are the monitoring half of “restricted and monitored”
CC6.5	Physical assets containing data are handled and disposed of properly	Decommissioned cameras and their storage are assets
CC7.2	System components are monitored for anomalies that indicate a problem	Cameras are system components; their failures are anomalies
CC7.3 / CC7.4	Detected events are evaluated and responded to	A camera outage is an event with a required response trail
A1.2	Environmental protections and recovery infrastructure are maintained	Applies only if Availability is in your scope

Security, the common criteria, is mandatory in every SOC 2. Availability, Confidentiality, Processing Integrity, and Privacy are elective. So CC6.4 and CC7.2 are the two that will find you regardless of how narrowly you scoped the engagement.

Check whether your cameras are in scope at all

Before you build anything, resolve scope, because a meaningful number of teams spend weeks preparing camera evidence that the auditor was never going to test.

If your in-scope systems run entirely in a cloud or colocation provider, physical access to that facility is almost always handled through the subservice organization carve-out. The provider’s own attestation covers their data center, their report gets referenced in yours, and your auditor tests the complementary controls you are responsible for instead. Your cameras are not their data center’s cameras.

What stays in scope is your own space. Offices where in-scope personnel work, rooms holding network gear or backup media, anywhere your control narrative claims physical restriction. If your description of the system says access to a specific area is restricted and monitored, the auditor will test that claim against that area, and cameras you own become evidence.

The practical rule: your camera fleet is in scope for exactly the locations your system description says it protects. Write that description carefully. Every location it names becomes a population the auditor can sample.

Type I and Type II ask different questions

A Type I report opines on whether controls were suitably designed as of a single date. For cameras, that is a design conversation. Do you have coverage of the areas your narrative claims, is access to recorded material restricted, does a monitoring and response process exist on paper and in configuration. A walkthrough and current-state artifacts largely satisfy it.

A Type II report opines on whether those controls operated effectively throughout a period, typically three to twelve months. That single word, throughout, is the entire difficulty. The auditor is no longer asking whether you have a camera at the server room door. They are asking whether it worked on a date they will choose, and they will choose it after the period has already closed.

You cannot go back and generate that. Policies can be written in prep week. Operational history cannot.

The four properties of camera evidence that passes

Auditors do not grade evidence on how polished it looks. They grade it on four properties, and camera records fail on the fourth more often than the first three combined.

It is per device. The population is your camera list. Fleet-level averages do not answer a question about the camera at the media room door. If you cannot produce history for one named device, you cannot produce it for a sample.

It is continuous across the period. Gaps in the record are treated as gaps in the control, not as gaps in the paperwork. An auditor reading a history that starts two months into a twelve-month period has a scope problem, not a formatting problem.

It was generated as events happened. Contemporaneous records carry weight because they could not have been shaped by knowing what would be sampled. Reconstructions carry very little, and an auditor who suspects reconstruction will widen the testing rather than narrow it.

The population is complete and accurate. This is the property nobody expects. When evidence is produced by your own systems, the auditor has to satisfy themselves that the list you handed over is the whole list. If your camera inventory is a maintained spreadsheet, they will ask how you know a camera is not missing from it, and how you know the report you exported reflects everything the source system holds. A perfectly detailed uptime report drawn from an incomplete inventory tests nothing, because the sample was drawn from the wrong universe.

That last point is why an inventory that maintains itself is worth more at audit time than a beautifully formatted list somebody curated by hand.

What gets rejected

Common camera artifacts and how they usually land:

• Screenshots of a live view. Evidence that the camera worked the moment you pressed the button. Says nothing about the period.
• A photo of the video wall. Same problem, plus no per-device attribution.
• “We would have noticed if it were down.” Detection by human observation is not a control an auditor can test. It generates no record and no timeline.
• A ticket queue with no detection times. Tickets showing repairs are useful, but without a detection timestamp the auditor cannot evaluate whether events were identified and responded to in a defined window, which is the CC7.3 and CC7.4 question.
• Retention policy documents offered instead of retention evidence. The policy is the design. Type II wants operation.
• A fleet health report exported the week before fieldwork. Fine as a summary if the underlying records are continuous. Fatal if the tool started collecting three weeks ago, because the report then covers three weeks of a twelve-month period.

The three requests that decide the outcome

Fieldwork on physical security is usually short. In our experience across camera fleets, these are the requests that separate a clean walkthrough from a finding:

1. “Give me the complete list of cameras covering in-scope areas, and tell me how you know it is complete.” This is the population question. Answer it with a system-maintained inventory and the completeness question resolves in one exchange.
2. “For these three cameras, show me operational history for the period, including every outage and how long each lasted.” Nobody expects zero outages. They expect you to know about each one and to show it was detected and closed. This is also where time synchronization comes up, because records with drifting clocks are hard to correlate and easy to challenge, and it is worth knowing the ordinary reasons devices drop out, which we covered in why security cameras go offline across multiple sites.
3. “Show me who could view or export recorded material during the period, and when that access changed.” Joiners, movers, leavers, applied to the camera system rather than to the SaaS stack. Shared admin accounts fail this immediately, and rotating them without disrupting recording is its own problem, covered in rotating camera passwords without breaking the VMS.

The broader walkthrough, including the frameworks beyond SOC 2 that ask similar questions, is in what auditors actually ask about camera systems.

Doing this across 500 cameras

At ten cameras, the manual version is tedious but survivable. At several hundred across multiple sites, three problems compound. The inventory drifts, so the population is arguable. The history was never kept per device, so requests two and three become archaeology. And the outages that did happen were noticed by whoever happened to walk past a monitor, which produces no timeline at all.

That is the gap MentatNOC is built to close. The platform keeps per-camera health and uptime history continuously, maintains the fleet inventory itself rather than leaving it to a spreadsheet somebody remembered to update, records every detection and every fix in a hash-chained audit log, and assembles a chosen period into an evidence pack you can hand across the table. MentatNOC helps you prove your controls operated; it does not certify anyone, and no platform makes an organization compliant on its own. MentatNOC is pursuing SOC 2 attestation; reports will be published when issued. The compliance and proof page shows what the evidence looks like, and you can pull a sample pack in the live platform demo.

Start the record before the period starts. A SOC 2 Type II is decided by what was being kept while nobody was watching, and the one thing preparation week cannot produce is the past.