Most failed surveillance systems fail at the moment they are needed. The cameras are recording, the screens look convincing, and then an incident happens and the footage is 720p at eight frames per second, the camera covering the relevant door was pointed at a car park, and recordings older than four days were silently overwritten because nobody sized the storage. The equipment worked exactly as installed. It was designed by someone counting cameras rather than asking what the footage was for.
We approach surveillance the way we approach any other infrastructure: define the requirement, size the system against it, isolate it properly and operate it deliberately.
Design before hardware
The useful question is not how many cameras but what each one must let you do. Identifying a stranger’s face, reading a number plate at speed, and observing that a delivery arrived are three different requirements with three different pixel densities, lens choices and lighting needs. A camera that satisfies the third will not satisfy the first, regardless of its megapixel count.
We work through this per location: field of view, mounting height, expected lighting through the day, and whether the scene demands wide dynamic range because it faces a glass entrance. Number plate capture in particular needs a dedicated camera with a controlled angle and shutter, not a general overview camera pointed hopefully at a gate.
Megapixels get oversold. Sensor size, lens quality and low-light performance usually matter more, and an 8 MP camera on a small sensor frequently produces worse usable night footage than a well-chosen 4 MP one, while consuming twice the storage.
Recording and retention
Storage is calculated, not estimated. Bitrate, camera count and retention determine capacity, and the result should be presented as a number you can check rather than a package tier. We size for the required retention with headroom, and use H.265 with smart codecs where the cameras support it, since the saving is substantial on mostly static scenes.
Recording servers need the same treatment as any other server: monitored disks, RAID with a tested rebuild, and alerting when a camera stops recording. A camera that has been offline for three weeks is an extremely common finding, and it is only ever discovered when someone goes looking for footage that does not exist. Recording failure should page somebody the same day.
Retention is a policy decision with legal weight, not a storage setting. We configure it explicitly, document why that period was chosen, and make deletion automatic.
Treating cameras as the attack surface they are
An IP camera is an embedded computer with a network stack, a web server and a long history of vulnerabilities. Large botnets have been assembled almost entirely from cameras and recorders exposed to the internet with unchanged credentials. Any camera deployment is therefore also a security project.
We place cameras on a dedicated VLAN with no internet route, replace default credentials, disable unused services such as UPnP and P2P cloud features, and keep firmware on a maintenance schedule. Remote viewing goes through a VPN or a controlled gateway, never through a port forwarded to a recorder. Where procurement rules matter, we also check device provenance, since several widely sold brands are restricted for public-sector use in some jurisdictions.
Access to footage is itself access to personal data. Accounts are individual rather than shared, viewing and export are logged, and export requires a stated reason.
Analytics that reduce work
Modern detection distinguishes a person from a vehicle from a branch moving in wind, which is the difference between alerts people act on and alerts people mute. Classic motion detection on an outdoor scene produces so many false alarms that it is usually switched off within a month.
We tune object detection, line crossing and loitering rules to the specific scene, and connect them to notifications only where somebody will genuinely respond. Analytics can run on the camera, on the recording server or on a small GPU, and the right answer depends on camera count and whether you want the video to stay on site.
Who this is for
This work suits organisations that already have a system installed and cannot rely on it, sites where surveillance is a regulatory or insurance requirement, and companies whose cameras were installed by a security firm without the IT department being involved and now sit unsegmented on the corporate network.
We handle the design, the network, the recording architecture, device hardening and the data protection questions. Where physical installation requires a nationally licensed security company, we work alongside one and remain responsible for the technical design and the systems it runs on.
Outcomes
When an incident occurs, the footage exists, covers the right area, is of usable quality, and can be exported with a record of who exported it. When an auditor asks how long you keep recordings and why, there is a written answer. And the cameras cannot be used as an entry point into the rest of the network.