Services
Preventive Maintenance
Scheduled inspection, health assessment and sample testing of enterprise access control, video and security server systems. Every visit produces a written deficiency report with prioritized recommendations.
Why it matters
Enterprise security systems degrade quietly
Most security equipment does not announce its own failure. It keeps looking correct from the operator position long after it has stopped doing its job.
A camera that stopped writing to disk still shows a live image on the video wall. A RAID array running degraded still serves footage. A backup job that has failed every night since a service account password changed still appears in the schedule with a green history from last quarter. A panel on a dead standby battery behaves normally until the power drops. Nothing on any of these looks wrong until something is asked of it.
The moment of discovery is almost always the worst available one. Footage is requested for an incident and the retention window turns out to be three weeks shorter than the policy says. An audit asks for a cardholder history and the database has been truncating since a volume filled. A camera that stopped recording on the 4th is discovered on the 26th, when someone finally needs what it was supposed to have captured. By then the gap cannot be repaired, only reported.
Preventive maintenance moves discovery forward. The point is not to polish equipment or to generate a visit record. It is to find the silent failures while they are still inexpensive to fix, and to hand the site a written list of what is wrong and what it matters to, ranked so that a limited budget goes to the right items first.
- Cameras recording nothing. Live view is fine, the stream never reaches storage, and no alarm was ever raised.
- Retention below policy. Configured for 90 days, actually holding 46, because throughput or camera count grew after commissioning.
- Degraded arrays and failed drives. Running on the last redundancy the array has, with no spare on site.
- Backups that have not run. A job that reports as scheduled but has not completed successfully in months.
- Panels on failed batteries. Standby power that will not survive the outage it exists for.
- Alarm lists nobody reads. Hundreds of standing trouble conditions, inside which a genuine new fault is now effectively invisible.
- Configuration drift. Doors, schedules and clearances that no longer match the operational intent, and no current backup of what the system holds.
What a maintenance visit covers
Scope is agreed in advance and set against the systems in place. The work below is what a full visit normally includes on an enterprise access control, video and server installation.
Controller and panel inspection
Physical and electrical condition of the equipment that keeps working when the head end is unavailable.
- Enclosure condition, tamper operation, evidence of heat, corrosion or moisture
- Terminations and connections checked for looseness, corrosion and strain
- Standby battery condition, age and behaviour under load
- Power supply output measured under load rather than at rest
- Communication status of every downstream module and reader on the bus
- Firmware version recorded against known defects that apply to this site
Server health assessment
The platform the security application depends on, assessed against what that application actually needs.
- Service state, dependencies and behaviour after restart
- CPU, memory and disk headroom under normal and peak load
- Operating system patch level against what the security application supports
- Windows event log review for recurring errors and warnings
- Antivirus and endpoint agent exclusions covering security application paths
- Time synchronization across servers, controllers and cameras, which quietly breaks event correlation when it drifts
- Certificate and licence expiry dates recorded before they cause a partial outage
Storage and RAID review
Video storage is where silent loss accumulates fastest, because capacity, throughput and retention all interact.
- Array status, rebuild history and any drive reporting predictive failure
- Spare drive availability on site
- Volume capacity and growth rate
- Recording throughput against what the storage can sustain
- Actual retention measured per camera and compared with configured retention
- Archiving and offload behaviour where secondary storage is used
Database and backup checks
The record of who went where and when has a maintenance requirement of its own, and it is usually the least attended part of the system.
- Database size, growth rate and transaction log behaviour
- Archiving, purge and index maintenance jobs running as intended
- Backup job history reviewed for successful completion, not just for the presence of a schedule
- Whether backups are stored somewhere other than the server they protect
- Restore of a configuration backup tested where the site can provide a window
System alarm review
A long-standing alarm list is not noise. It is a fault list nobody has read, and it is where forming faults hide.
- Standing trouble and communication conditions listed and explained
- Repeat offenders identified across the period since the last visit
- Device health and status list reviewed against the as-built device count
- Error and retry counters compared against the previous visit to show trend
- Alarm conditions cleared down where resolved, so new faults become visible again
Firmware and software review
Version control on a live security system is a judgement call, not an automatic update policy. Both updating and not updating carry risk.
- Current versions recorded for application, controller firmware, camera firmware and device packs
- Known defects that affect the versions running at this site
- Compatibility checked across application, controllers, cameras and integrations before anything is proposed
- Recommendation of what to update, what to leave alone, and why
- Update work scoped separately and scheduled into a window rather than performed during an inspection
Device communication checks
Every device on the system, not a sample. A device count that no longer matches the as-built record is itself a finding.
- Online and offline state for every controller, module, reader and camera
- Bus error and retry counts on RS-485 and OSDP segments
- Network path checks to devices in remote buildings, including latency and loss
- Devices that have been offline long enough that the site has stopped noticing
- Devices present in the configuration that no longer physically exist
Sample functional testing
Testing is by sample, agreed in advance with your operations staff, and coordinated so anything briefly taken out of service is known before it happens.
- Card reads at selected doors, including a credential that should be refused
- Lock release and re-secure, door position and request-to-exit agreement
- Alarm annunciation reaching the operator position as expected
- Camera call-up from an access event where the integration exists
- Recording verified to disk and back from storage, not confirmed from the live view
- Failover, redundancy and reconnection exercised where the platform supports it and a window allows
Configuration backup
A current, dated, off-server copy of the system configuration is the difference between a rebuild measured in hours and one measured in weeks.
- Application and database configuration exported
- Controller and panel configuration captured
- Camera configuration captured where the platform supports export
- Licence records and system inventory documented
- Copies stored off the server, dated, and their location recorded in the report
Found on a maintenance visit, or found the hard way
The same fault has two discovery paths. The difference is who finds it, when, and what it costs by then.
| On a maintenance visit | Left to reactive service | |
|---|---|---|
| Camera not recording | Checked against every camera in the recording configuration, including the ones nobody watches. | Found when footage is requested and the recording is not there. |
| Retention below policy | Measured retention compared with configured retention, per camera. | Found at the point an investigation needs footage older than the system actually holds. |
| Degraded RAID array | Array status and drive health reviewed while the array still has redundancy left. | Usually reported after a second drive fails and the volume is gone. |
| Failed backup job | Backup history reviewed for successful completion rather than for the presence of a schedule. | Found during a recovery, which is the one moment it cannot be fixed. |
| Dead standby battery | Battery condition and behaviour under load checked at the panel. | Found during the power interruption the battery existed for. |
| Standing trouble alarms | Alarm list reviewed, explained and cleared down so new faults are visible. | Buried in a list too long for operators to read, hiding the next real fault. |
| Forming intermittent fault | Rising error and retry counts caught while the device is still working. | Addressed after it becomes a repeat call and several attendances. |
| Configuration drift | Current configuration reviewed against documented intent and backed up. | Noticed when a change is needed and nobody can say what the current state is. |
| Firmware defect affecting this site | Versions reviewed against known defects and an update recommended with reasons. | Diagnosed after the defect causes an outage. |
| Undocumented system | Documentation and configuration backup refreshed at each visit. | Reconstructed from scratch under time pressure during a failure. |
Preventive maintenance reduces the number of failures that reach an operator or an investigation. It does not remove the need for reactive service, and no inspection predicts every failure. Visit frequency, scope, coverage and any response commitments are set in each customer’s approved service agreement rather than assumed here.
The deliverable
What you receive is the report, not the visit
A maintenance visit that ends with a technician saying everything looks fine has given the site nothing it can act on, budget for, or show an auditor.
Every visit produces a written deficiency report. It records what was inspected, what was tested, what was found, what it means operationally and what we recommend doing about it. It is written to be read by a security manager, an IT lead and a finance approver, because those are the three people who between them decide whether anything gets fixed.
Recommendations are prioritized, and the priority is based on operational consequence rather than on the value of the work. Items are grouped into three bands: correct now, where a security function or a recorded evidence stream is currently lost or at immediate risk; plan and budget, where a component is degrading and will fail on a predictable path; and monitor, where a condition is noted and re-checked at the next visit rather than acted on today.
- Scope of the visit. What was inspected and tested, and what was explicitly out of scope.
- Each deficiency, described plainly. The device or subsystem, what is wrong with it, and how that was determined.
- Operational consequence. What the site loses if it is not corrected: a door that will not secure, a camera not producing evidence, a system that cannot be recovered.
- Priority band. Correct now, plan and budget, or monitor.
- Recommended correction. Whether the item is a repair, a replacement, a configuration change, a version decision or something the organization needs to decide on policy grounds.
- Items outside our scope. Where the correction is cabling installation, construction or another trade’s responsibility, it is still reported so that it is visible and can be assigned.
- Change since the last visit. What was corrected, what is still open and what is trending in the wrong direction.
How a visit runs
- 01 Scope agreed in advance — Systems, sites, device counts and the extent of functional testing are confirmed before the visit, along with any areas requiring escort, clearance or restricted access. In correctional, hospital and government settings that agreement is made with operations, not assumed.
- 02 Remote review first — Where the site permits remote access, alarm lists, logs, backup history, storage state and device status are reviewed before anyone arrives. That means on-site time is spent on the things that need hands and eyes rather than on reading screens.
- 03 Inspection and health assessment — Controllers, panels, power, servers, storage, database and communications are inspected and measured. Findings are recorded as they are made, including the readings behind them.
- 04 Sample functional testing — Testing is coordinated with operations so any door, camera or alarm point briefly out of service is known in advance and restored before the technician leaves that area.
- 05 Configuration backup taken — A dated configuration backup is captured and stored where it survives the failure of the server it came from.
- 06 Report issued — The deficiency report is written up and delivered after the visit, with priorities assigned and anything urgent flagged on the day rather than held for the document.
- 07 Deficiencies followed through — Open items are quoted, scheduled, escalated or deliberately carried forward with the site’s agreement. The next visit reports on their status. Nothing is silently dropped between visits.
Scheduling
One visit or a recurring program
Maintenance can be arranged as a single assessment visit, which is often the right starting point on a system whose current condition is unknown, or as a recurring program under a service agreement. A first visit on an unfamiliar system typically finds more than later ones do, and the report from it is a reasonable basis for deciding how often the system needs attention afterwards.
Frequency, scope, coverage hours and any response targets are defined in the approved service agreement rather than fixed here. Coverage hours are 8:00 AM – 5PM, with after-hours arrangements at 24/7/365. See service agreements for how visits, support and priority are structured, and troubleshooting and system restoration for faults that need diagnosis now rather than at the next visit.
Common questions
How often should an enterprise security system be maintained?
It depends on what the system protects, how large it is and how much it changes. A high-security site with a large door count, continuous recording and evidentiary retention requirements needs attention more often than a small office system that has not been touched in two years. Systems under active construction or expansion also drift faster, because configuration changes accumulate between visits.
Rather than quote a fixed interval, we would rather assess the system once and recommend an interval based on what that visit finds. The first report usually makes the answer obvious: a system with a long deficiency list and no configuration backup needs a shorter cycle than one that comes back clean. Intervals are then set in the service agreement.
Will a maintenance visit disrupt operations?
Most of it does not. Inspection, health assessment, log review, storage and database checks and configuration backup run against a live system without interrupting anything.
Functional testing is the part that touches operations, because verifying that a door secures means operating that door. That work is scoped and scheduled with your staff in advance: which doors, at what time, for how long, and who needs to be told. In correctional, hospital and data centre environments testing is normally arranged around movement schedules, clinical activity or change windows, and some points are tested only during an approved outage window.
Anything taken out of service is restored and verified before the technician leaves that area, and that verification is recorded in the report.
What does the report actually contain?
The scope of the visit, the findings, and prioritized recommendations. Each deficiency is described with the device or subsystem it affects, what is wrong, how it was determined and what the site loses if it is not corrected. Recommendations are banded into correct now, plan and budget, and monitor.
It also records what was tested and passed, current firmware and software versions, storage and retention figures, backup status, and where the configuration backup from that visit is stored. On a recurring program it carries forward the status of previously reported items so the trend is visible.
It is written in plain terms deliberately. A report that only a security technician can read cannot be used to obtain budget approval, and an unfunded deficiency is an unfixed deficiency.
Our system is only two years old. Is maintenance worth it yet?
Newer systems fail differently, not less. Hardware wear is not the main issue at two years. Configuration drift, storage growth, retention falling below policy as cameras are added, backup jobs that stopped after a credential change, firmware left at the version shipped at commissioning, and integrations broken by an update on one side are all common well inside the first three years.
There is also a commissioning question worth answering early. Systems are frequently handed over with items that were never quite finished: devices in the configuration that were never installed, test credentials still active, recording schedules that do not match the retention policy that was specified. A first maintenance visit on a young system finds those while the installing contractor may still be responsible for them.
What happens to the deficiencies you find?
They are reported, priced where you want them priced, and tracked. Nothing is corrected beyond the agreed scope without your approval, with one exception: where something can be safely put right during the visit at no material cost, we do it and record that it was done.
From there the site decides. Items may be scheduled as repair work, deferred with a decision recorded, assigned to another contractor where the correction is outside our scope, or carried into a capital plan where the answer is replacement rather than repair. The next visit reports on the status of every open item, so a deferred deficiency stays visible instead of disappearing between reports.
Can you maintain a system another company installed and still supports?
Yes, and it is a common arrangement. An independent inspection of a system maintained by the company that installed it is a reasonable control, in the same way that financial statements are not audited by the people who prepared them. We report what we find, including work that falls to the incumbent under an existing contract or warranty.
We do not require the site to change vendors and we do not use a maintenance visit as a sales exercise for equipment. Skyfal does not sell cameras or panels. See about Skyfal.
Find out what your system is actually doing
Start with one assessment visit and a written deficiency report, then decide what the ongoing interval should be.