Security Network Documentation: IP Addresses, Ports and Device Registers

Security network documentation should let an authorised technician identify a device, find it on site, confirm its network settings and understand which connections it needs. Start with a device register, an IP address schedule, a physical port map and a service dependency register. Give each record an owner, revision and verification date so the information remains useful after installation.

For New Zealand security installers and integrators, the practical test is straightforward: could the next technician replace a failed camera, investigate a disconnected controller or explain a firewall request using the handover pack? A list of addresses alone rarely answers all three questions.

What belongs in a security network handover pack?

Use linked records rather than one oversized document containing everything. A small site can use separate tabs in a controlled workbook; a larger organisation may already maintain an asset management system and IP address management platform. Agree which system is authoritative before producing a competing copy.

The schedule supports the wider security system commissioning checklist. Keep this article's records focused on network identification and traceability; functional acceptance testing still needs its own results.

Build a device register with stable identities

Assign an asset ID that remains meaningful if an address, hostname or switch connection changes. For example, CAM-014 can identify a loading-bay camera throughout its service life, while the serial number identifies the particular unit currently fulfilling that role.

Record the device role, exact manufacturer and model, serial number, relevant MAC addresses, hostname, physical location, installed firmware or software version, responsible organisation and last verification date. Include the associated recorder channel or controller reference where it helps technicians connect the physical asset to the application.

Do not treat a MAC address as a substitute for a serial number or physical check. Equipment with several interfaces can have several MAC addresses. A replacement unit also changes the hardware identity while retaining the same functional role.

For lifecycle planning, add support-status evidence and a review date when that information is available from the manufacturer. Axis's Device Manager security guide describes inventory functions including model information, device status and software support planning. Those functions concern supported Axis equipment; they do not establish that a discovery tool will provide a complete mixed-brand site register.

Separate device identity from confidential access

The general register should contain an approved credential-vault reference and the access owner, rather than readable passwords, recovery codes or private keys. Record whether the service account belongs to the client or maintenance provider and who can authorise access changes.

Restrict the documentation itself. A network map may expose equipment locations and management paths even when it contains no passwords. Give the client an agreed controlled copy and ensure service personnel know where to find the current version.

Record IP allocations without creating conflicts

Agree addressing with the client's IT administrator before connecting new equipment. Ask who controls the subnet, which ranges are reserved, how DHCP is managed and which addressing method is approved for each device type.

For every relevant interface, record the address, prefix length or subnet mask, allocation method, VLAN where applicable, and the approved gateway, DNS and time-service settings where required. Mark a setting as intentionally unused when that is the agreed design; an empty cell should not leave the reader guessing.

A manually configured static address requires coordination with the site's allocation records and DHCP configuration. A DHCP reservation provides centrally managed allocation but depends on the reservation matching the actual client identity and the device using DHCP. Neither method removes the need to test the installed result.

The following is a hypothetical documentation example, not an allocation to copy onto a live network:

The example uses a private address, but that does not make it suitable for every site. Confirm that the proposed range does not conflict with existing networks or remote-access arrangements. Where IPv6 is enabled, document its addressing and management policy too rather than assuming an IPv4 schedule describes every available path.

Distinguish physical ports from service ports

A physical switch port is the socket or interface connecting equipment. A TCP or UDP port identifies a service endpoint in network communications. Writing “port 14” without context can therefore misdirect both the network administrator and the field technician.

Use explicit column names such as switch interface, destination service port and transport protocol. This small distinction makes fault reports and firewall requests considerably easier to interpret.

Map the complete physical connection

For CAM-014, a useful path might read: camera tail, outlet LB-14, cable C-014, patch panel PP-02 position 14, patch lead PL-014, switch SW-02 interface 14. This is an illustrative naming scheme; use the client's established convention when one exists.

Record the configured VLAN membership, expected link speed and power arrangement where relevant. Identify an injector, extender, fibre converter or local supply as a separate asset when it adds a dependency worth tracing. The PoE accessories collection is relevant when specifying those components, but an accessory's suitability must be established from its own specifications.

Separate equipment ratings, configured limits and observed readings. A measured PoE reading at commissioning is a dated observation, not proof of the highest possible load. Use the CCTV PoE switch sizing guide when reviewing capacity alongside the connection schedule.

Label the outlet, patch-panel position and device consistently. Before unplugging an unidentified lead, establish what it serves and agree any interruption with the responsible site contact.

Create a service dependency register

Document required communications as a set of justified dependencies. For each one, capture the initiating system, destination, TCP or UDP transport, configured destination port or supported range, purpose, manufacturer reference and test result. Add the firewall rule reference and approving owner where traffic crosses a controlled boundary.

A record should say whether it describes a planned requirement, an approved rule or a verified working connection. These are different states. Include return-traffic handling in the network administrator's review rather than treating every response as a separate unrestricted allowance.

For illustration, the Axis AXIS OS hardening guide lists HTTPS on TCP 443, RTSP on TCP 554 and RTP using UDP ports within an automatically allocated range. These examples explain why a single port number may not describe a complete video workflow. They are not a universal firewall template: verify the actual device configuration, software version and selected streaming transport.

Record supporting dependencies such as approved name resolution, time services, certificate services or remote-management destinations when the installed system needs them. For cloud-connected functions, retain the manufacturer's current destination guidance and its review date; do not replace changing service requirements with an undocumented guess.

Keep network segmentation design and firewall implementation in the approved network design. This register should reference those decisions and explain dependencies without becoming an alternative set of traffic rules.

Verify the records against the installed system

Complete verification during an agreed maintenance window, using authorised access. Discovery results, drawings and supplier schedules are starting points rather than proof of the final installation.

1. Compare each device's model and serial number with the register and physical label.
2. Read the installed interface settings and compare them with the approved address schedule.
3. Reconcile the MAC or client identity with the relevant reservation and switch records.
4. Trace the physical connection and confirm the documented switch interface.
5. Check management access from the approved administration location.
6. Test the functions that depend on the network, including recording and playback, controller events or intercom calls as applicable.
7. Confirm the agreed restricted paths remain restricted, under the client's test plan.
8. Record the date, tester, result, exceptions and evidence reference.

A successful ping does not demonstrate that recording, event delivery or remote administration works. Conversely, a device configured not to answer ping may still provide its intended service. Define success around the required application function and retain the relevant evidence.

For an address correction, repeat the affected application checks and confirm the old address no longer causes confusion in the records. For a replacement camera, update the hardware identity, reservation if applicable, application association and connection evidence. Use the CCTV field tester guide for checks that can support field diagnosis before final system acceptance.

Maintain revision control and recovery references

Place a document owner, revision, date and approval state on the handover pack. Keep superseded versions distinguishable from the current operational record. Agree which changes trigger an update, including replacements, firmware changes, switch moves, address changes and remote-access changes.

Record where configuration backups are held, which device and software version they cover, who can retrieve them and when recovery was last tested. A backup filename alone does not demonstrate that restoration will succeed. Retain dependencies such as licences and protected credentials through the client's approved process.

At handover, ask a technician who did not build the schedule to trace one device from its physical location to its address, application and recovery reference. Any missing step is a useful correction before the pack becomes operational documentation.

Frequently asked questions

What should a security network device register contain?

Include a stable asset ID, device role, exact model, serial number, relevant interface identities, location, installed software version, responsible owner and verification date. Link it to the address schedule, physical port map and application record.

Should CCTV devices use static addresses or DHCP reservations?

Use the method approved by the client's network administrator and supported by the equipment. Coordinate manual addresses with DHCP and allocation records; for reservations, verify the actual client identity and confirm that the device uses DHCP.

Is a switch port number the same as a TCP or UDP port?

No. A switch port identifies a physical or logical switch interface. A TCP or UDP port identifies a service endpoint. Label both explicitly in the documentation to prevent confusion.

Should passwords be included in the handover spreadsheet?

Keep readable passwords, private keys and recovery codes out of the general register. Include a controlled vault reference, access owner and authorised retrieval process, and restrict access to the documentation itself.

When should security network documentation be updated?

Update affected records whenever equipment, addressing, firmware, patching, dependencies or access arrangements change. Verify the installed result, retain the change reference and issue a clearly identified current revision.

Need help specifying the network equipment?

Contact Essential Security Supplies with your equipment schedule, proposed connection map and project requirements for trade specification assistance. Keep site credentials and detailed network records within your approved secure sharing process.