What auditors actually ask about camera systems

Auditors ask five things about camera systems: what you have, whether it was working during the audit period, who can access it, how it is maintained and hardened, and whether you can prove any of that with records kept as it happened. The control language changes from framework to framework, but the walkthrough is remarkably consistent, and so is the place where teams fail it. This post lists the actual questions, maps them to the frameworks that generate them, and explains why the last question is the one that produces findings.

Why cameras are in scope at all

Cameras show up in audits wearing two hats. They are a control: most frameworks require physical access to sensitive areas to be restricted and monitored, and cameras are how most organizations satisfy the monitoring half. And they are evidence: when an auditor tests whether the physical access control operated, camera system records are often what gets sampled.

That dual role is why a camera problem escalates. A broken door sensor is one failed control. A camera system nobody can produce records for undermines both the control and the evidence for other controls that leaned on it.

Question one: what do you have

The walkthrough starts with inventory, and it is less trivial than it sounds:

• Show me the camera inventory. Make, model, location, and who owns each device. Auditors compare this list against what they see walking the facility, and the delta becomes a question.
• Do cameras cover the required areas? Entry and exit points, server rooms, areas where regulated data lives. Coverage gaps against your own policy are findings.
• Who is responsible for this system? A camera fleet that belongs to “facilities, sort of, or maybe IT” tends to fail the questions that follow.

Question two: was it working

This is the heart of the audit, and the question teams most often cannot answer:

• Was this camera operational during the audit period? Not today. During the period. An auditor picks a camera covering a sensitive area and asks for its operational history for the last six or twelve months.
• Were there outages, and how long did they last? Every fleet has outages. Auditors do not expect zero. They expect you to know about each one, and cameras fail for reasons that are well understood and detectable, which we covered in why security cameras go offline across multiple sites.
• Are the timestamps trustworthy? Recorded material with drifting clocks has degraded evidentiary value, and auditors who work physical security know to ask how time is kept accurate across devices.

Question three: who can access it

Recorded material is sensitive by definition, so the access questions mirror any other data system:

• Who can view live and recorded material, and who can export it? A named list, not a shrug.
• How is access granted and revoked? Joiners, movers, leavers. The auditor will pick a departed employee and ask when their access ended.
• Are shared or default accounts in use? Camera systems are notorious for the one admin password everyone knows. That answer fails modern audits.

Question four: how is it maintained

Auditors treat cameras as computers, because they are:

• How do you learn a camera has failed? “Someone notices eventually” is a finding phrased politely. The expected answer is monitoring that detects failures the day they happen, with a ticket trail from detection to repair.
• Are devices kept current? Firmware posture across the fleet, and how you know. A fleet where nobody can state the version spread fails this quickly.
• Have defaults been hardened? Changed default credentials, disabled unused services, certificates that are valid and tracked rather than expired and forgotten.

Question five: can you prove it

Everything above collapses into the fifth question, because an assertion without records is just an assertion. The hard property here is that operational evidence must be contemporaneous. You can write a policy retroactively. You cannot retroactively produce an uptime history, a detection-to-repair trail, or proof that a camera was recording on a specific Tuesday in March. Either the records were being kept as it happened, or the answer is no.

Good evidence has a consistent shape: it is per-device, it covers the whole period without gaps, it was generated automatically rather than assembled by hand the week before the audit, and it is tamper-evident enough that the auditor can rely on it. Screenshots taken during the walkthrough do not have that shape. A year of continuous health records does.

When there is an uptime SLA in the contract

Many camera systems sit under a service agreement with an availability commitment, and the moment a number appears in a contract it becomes something an auditor can test. A surveillance system SLA usually names three things: a monthly uptime percentage, a maximum response time for critical failures, and a mean time to repair target, often with service credits attached when the threshold is missed.

The trap is reporting an uptime number you cannot substantiate per device. One fleet-wide availability figure assembled by hand is weaker than no figure at all, because it invites an immediate question about how it was calculated and from which population, and neither answer tends to be ready. A defensible uptime report is per camera, covers the whole month without gaps, and comes from records collected while the month was happening rather than totaled afterward.

It is also worth confirming the number from outside the system being measured. A recorder reporting on its own availability is a self-assessment, and a second vantage point is what turns it into evidence. That distinction matters most when credits are on the line, because the party who pays them is usually the party producing the report.

Where each framework generates these questions

Framework	Where cameras come up
SOC 2	Physical access criteria: facilities restricted and monitored, with evidence it operated all period
PCI DSS	Requirement 9: entry and exit to sensitive areas monitored, monitoring data kept at least three months
HIPAA	Security Rule physical safeguards: facility access controls plus documented repair records
CMMC / NIST 800-171	Physical protection family: protect and monitor the facility and its support infrastructure
NDAA Section 889	Procurement: no covered-manufacturer surveillance equipment in federal supply chains
Cyber insurance	Application questionnaires: physical security attestations that must survive a claim investigation

The details differ, and none of these frameworks exist for cameras specifically. But every one of them, tested seriously, walks the same five gates: inventory, operation, access, upkeep, proof.

Walking in with the evidence already built

Most teams pass gates one and three with a spreadsheet and an afternoon. Gates two, four, and five are where audit prep turns into weeks of reconstruction, because the underlying records either exist continuously or they do not exist at all.

That is the problem MentatNOC is built for. The platform keeps per-camera health and uptime history as it happens, tracks firmware and certificate posture across the fleet, records every failure and fix as an auditable trail, and assembles the audit 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 tool makes you compliant by itself. MentatNOC is pursuing SOC 2 attestation; reports will be published when issued. You can see what the evidence looks like on the compliance and proof page, or pull a sample evidence pack in the live platform demo.

The uncomfortable truth about camera audits is that the outcome is decided months before the auditor arrives. If the records were being kept, the walkthrough is an hour. If they were not, no amount of preparation week recreates them.