Requirements for Testing Structured Cabling (SCS) in Tenders: Reports and Acceptance

Why specify testing and reports separately in the tender

Structured cabling often looks “ready” on handover day: cables are in place, outlets installed, link LEDs lit on the switch. Problems usually surface later, under real load: IP telephony, CCTV, Wi‑Fi, large file transfers, PoE.

Common surprises after handover include pinout mistakes and swapped pairs, excessive untwisting at an outlet, poor contact in a keystone or punchdown, exceeded line length, sharp bends and crushes in trays. As a result the network may "work" but show packet loss, reduced speeds, unstable PoE and intermittent disconnects.

It’s important to understand the difference: a continuity check or a lit link only confirm basic connectivity. They don’t answer the main question: does the line meet the category requirements (for example Cat.6) and will it sustain gigabit without errors over the full length.

In a tender it’s useful to separate three things:

• installation (how it was laid and terminated);
• basic testing (minimal integrity tests);
• line certification (measurements by a certifying tester against a standard with a Pass/Fail verdict).

If testing and reporting requirements are not written down, the client has almost no verifiable facts for acceptance or dispute.

To make acceptance objective, state in advance that the contractor must deliver:

• measurement reports for each line with Pass/Fail and test parameters;
• tester details (model, adapters), calibration/verification records, test date and operator;
• mapping of results to labels and the cable register;
• a final report showing exactly what was handed over.

Then disputes are not about impressions but about specific lines with specific results.

Levels of testing and what you actually need

There is a difference between “link lights” and “a line that will reliably work for years.” If you don’t lock this down in advance, a contractor can hand over a network by the ‘‘it connects’’ principle, and hidden defects will show during operation.

Typically three verification levels are distinguished:

1. Basic checks: continuity, correct pinout, no shorts, basic length. These confirm the conductor is connected but not that it will carry the required speed.

2. Qualification: verifies the line can carry a specified service (for example 1G/10G) in the current configuration. Useful for quick decisions but does not replace category compliance.

3. Certification: a full set of measurements according to the category (copper) or class (fiber) with a Pass/Fail verdict. This is the “exam” after which the network can be accepted confidently.

For twisted pair, “it works” usually stops at a basic check. “Meets the standard” starts with certification and includes interference and loss measurements (for example NEXT/PSNEXT, ACR, Return Loss), not just pinout.

For fiber the logic is similar: minimally check continuity and polarity, while acceptance usually requires loss measurements (OLTS) and, where critical, an OTDR trace to see splices, connectors and problematic spots.

The choice of level depends on downtime cost:

• office: certification of copper to required category, fiber by loss; qualification can be an additional check;
• school: 100% basic checks and certification of key lines so you don’t spend days chasing intermittent ports;
• hospital: full certification and complete protocol sets, because failures impact processes and safety;
• data center: certify everything, plus OTDR on trunks and strict loss thresholds.

If the network carries critical services, require certification, not just a link check.

How to describe the site and SCS scope so reports are comparable

To be able to verify and compare SCS reports between contractors, you must describe uniformly what is being built and how things will be counted. Otherwise protocols will define different “lines,” different lengths and different acceptance levels, and acceptance becomes an argument.

Fix the category and class: for example Cat.6 for Class E or Cat.6A for Class EA. Specify whether measurements confirm the Permanent Link or the Channel, and what length ranges are acceptable (if important for the project).

Describe topology with simple terms: where are trunks, horizontals, how many cross‑connects, which zones (floor, wing, server room), and types of outlets (RJ‑45 outlet, consolidation point, patch panel port). This sets a common structure for reports and labeling.

Clarify what is considered a “line” in protocols: from which port to which port, and in which test mode. For example: “patch‑panel port in rack 3.1 - outlet 3.1‑215, Permanent Link test, adapters per the tester manufacturer.” This is critical when drafting SCS testing requirements in the tender.

Briefly fix component composition and basic installation rules: cable category and type (including shielding and fire class), outlets and patch panels, patch cords (category, lengths, factory‑made), tray and bend‑radius rules, grounding rules for shields and racks (if applicable).

A common mismatch: one contractor tests the Channel including patch cords while another tests only the Permanent Link. Results will be incomparable even if the cable work is identical. Define line boundaries and test type in a single sentence in the specification.

Measurement reports to request for twisted pair

To avoid acceptance being a discussion of words, fix in advance which report you expect per line. Protocols from a simple continuity tester do not replace certification for twisted pair lines.

For copper lines reports should show not only Pass/Fail but also actual values and margin. Margin is how much the result exceeds the standard threshold. If margin is close to zero, the line may start failing after a retermination, adding a patch cord or with increased interference.

Minimum required content in the report

At minimum require:

• line identifier (label at both ends) and location: rack, panel, port, outlet;
• tester model, adapter type, firmware version, selected standard/limit (ISO/IEC or TIA, class/category);
• test mode: Permanent Link or Channel (as decided in the project);
• table of parameters with Pass/Fail and margin for each parameter;
• calibration/verification data: certificate number, date and validity (or other confirming document).

Permanent Link is typically used for acceptance of fixed wiring (cable, outlet, cross‑connect). Channel is used if you will include patch cords; then you must predefine which patch cords are part of the Channel and who supplies them.

Parameters that should appear in the report

Ask that the report include the wire map and length, plus key frequency parameters: Insertion Loss, NEXT/PSNEXT, Return Loss, ACR (often ACR‑N and ACR‑F), propagation delay and skew.

A line can pass length and wire map but fail on Return Loss or NEXT due to sloppy pair separation at the outlet. Under load this shows as odd disconnects and speed drops, and a certification report reveals it immediately.

If the project includes fiber: measurements and reports to request

For fiber, separate two kinds of checks: loss measurement (OLTS) and reflectometry (OTDR). OLTS shows total channel loss and suits a pass/fail acceptance. OTDR produces a trace and helps locate the cause: a bad splice, a tight bend, a dirty connector, or an extra connector.

OLTS is usually enough when lines are short, routes are simple and installation is typical. Require OTDR where disputes may arise or the route is complex: long trunks between buildings, many splices and joints, no access after finishing, critical infrastructure (DC, hospital, finance), or when rework occurred during installation.

To make requirements unambiguous, record baseline data: fiber type (SM/MM), fiber count, expected lengths, connector types, polarity, and the allowed loss budget. It’s best to state the budget numerically: “no more than X dB for Y length” accounting for connectors and splices.

Also require cleaning and inspecting endfaces before measurement. A dirty endface often gives inconsistent results and later it's hard to prove the root cause.

In reports demand not just raw files from the tester but a clear per‑line summary: label, length and wavelengths measured, total loss and Pass/Fail against the budget. For OTDR include an event table (splice, connector, bend) with distance and loss, plus a list of lines that require rework.

Labeling: rules to avoid confusion

Labeling in SCS is not decorative — it links the actual line to the measurement report, the drawing and the cable register. If the format isn’t set in the tender, the contractor will label “as they’re used to,” and on acceptance you will find duplicates, omissions and mismatches between floors.

Mandate a single ID format that reads the same everywhere: rack (or cabinet), patch panel, port, and for the workplace — the outlet. The key is that the outlet ID and the panel port ID follow one logic, not the memory of the installer.

A practical approach is short codes without extra words. For example: panel: R01‑P02‑24. Outlet: F03‑RM305‑02 (floor 3, room 305, outlet 2). Then documents can show an unambiguous mapping: R01‑P02‑24 = F03‑RM305‑02.

In the specification fix:

• where to label: both ends of every cable, the face of the outlet, panel next to the port;
• how to label: printed tape/labels, not handwritten with a marker;
• durability requirements: labels must not peel or rub off during cleaning;
• uniqueness across the whole site (no “each floor has port 01”).

Also request a port mapping table: switch port - panel port - outlet, and require the line ID in test reports to match the labels on panel and outlet.

As‑built documentation: drawings, plans and the cable register

As‑built documentation is what allows you to accept the SCS and then maintain it without guesswork. If you don’t require it up front, the contractor will hand over “what happened” and any post‑move rework will be costly.

As‑built drawings are the final “as installed” record accounting for all site changes. State in the tender that acceptance is by as‑built drawings, while design documents are the baseline.

Minimum set to request with measurement reports:

• floor plans with all outlets and their numbers, plus rack/cabinet locations;
• route diagrams (trays, ducts, wall penetrations) showing nodes and concealed transitions;
• cross‑connect diagrams: which patch panel ports connect to which switch ports, ports reserved, labeling on active equipment;
• cable register: line from‑to, actual length, category, route, labels at both ends;
• change log: what and why was altered compared to the design.

Specify delivery formats: PDF for viewing and editable sources (for example DWG or another format you use). The important part is consistency. Outlet numbers on drawings must match line IDs in the register and IDs in the test reports.

Photo documentation: what to require to assess installation quality

Photos are a way to verify the quality of work where, after handover, everything will be hidden behind ducts, ceilings or rack doors. If you set photo rules in advance, acceptance becomes easier.

Request a basic set of photos per node: rack/cabinet overall (outside and inside), patch panels and organizers with readable labels, user outlets (overview and close‑up of ID), cable routes and penetrations, grounding points (if applicable).

It’s essential to require photos before closure: ceiling‑space routes, inside trays, wall penetrations, cable reserves at racks and outlets, bend radii and fixing points.

To prevent a random folder of 500 files, require a naming/caption rule: date, site, room, node, line identifier. This ID must match the cable register and protocols.

Also specify defect handling: the contractor photographs the defect and the fix with the same framing (before/after).

How to accept test results: verification, sampling and thresholds

Acceptance by reports only works when you receive not just screenshots of Pass results but the full set of source files. Specify upfront which files and formats must be delivered.

A typical delivery set:

• native tester files for all lines;
• PDF exports for review;
• consolidated CSV/Excel: ID, result, length, date, operator;
• unified folder structure: site -> floor/rack -> panel -> lines;
• list of lines not tested (if allowed) with reasons.

Then check completeness: the number of lines in the cable register must equal the number of reports, and IDs on outlets and panels must match IDs in the reports. Look for gaps (missing ports), duplicates, or reports without location mapping.

In the reports look beyond Pass. Risks often show up as: length close to limit, small margin on parameters, repeated anomalies for lines from the same tray or rack.

Set threshold rules in advance:

• any Fail -> rework and retest at the contractor’s expense;
• Pass with margin below agreed minimum -> investigation and retest;
• length “on the edge” -> route check and removal of unnecessary loops;
• ID or location mismatch -> report is invalid.

Record nonconformities in writing: a register with ID, location, issue, required action and deadline. Treat repeat measurements as a new package version with date and responsible signature.

Common specification mistakes that cause pain later

A familiar scenario: installation is finished, a folder contains “Pass” reports, and a week later intermittent drops, PoE errors or speed drops begin. The usual reason is vague testing and reporting requirements.

Typical mistakes:

• requesting Channel measurements when Permanent Link is needed for fixed wiring acceptance;
• not fixing category/class and getting a formal Pass to a weaker limit;
• not specifying ID format, leaving reports as a set of files that cannot be tied to floors, racks or ports.

In the specification explicitly require or forbid:

• test mode (Permanent Link or Channel) and where each is acceptable;
• standard and category/class that define Pass;
• line ID format (rack/panel/port - outlet/room) and mandatory match with labels;
• confirmation of tester calibration and measurement date;
• mandatory as‑built documentation package.

Simple example: a contractor hands over 300 lines and 300 PDFs labeled 001–300. Without drawings and a register you cannot prove that “001” is the right meeting room, and tracing ends will fall to your team.

Short checklist for tender documentation

Below is a compact set of phrases that help make SCS testing requirements verifiable in a tender.

Measurements and protocols

• 100% certification of twisted pair in Permanent Link mode (or Channel if specified) with declared category and standard.
• Report must include: length, wire map, NEXT/PSNEXT, Return Loss, ACR, delay and skew (as supported by the tester and chosen standard).
• Tester must have valid calibration/verification with confirming documents included in the handover.
• Delivery format: native measurement files + PDF/CSV export searchable by ID.
• Defect rule: lines with Fail are not accepted; rework and retest at contractor expense.

Also define naming structure for line IDs and require ID consistency in reports, labels and the cable register.

Documentation, labeling and photos

• Cable register: line ID, from‑to, length (design/actual), panel port, outlet number, test result.
• As‑built drawings and diagrams: outlets, routes, cross‑connects, rack/cabinet layout.
• Labeling: material, locations, unified format, match with the register and reports.
• Photo documentation: racks, entries, trays, penetrations, terminations on panels and outlets, readable labels; where needed include before/after photos prior to closing ducts.

For critical sites strengthen requirements: 100% testing, bidirectional OTDR for fiber trunks, and an expanded acceptance check by the client.

Example scenario: how to accept SCS without surprises after a move

Office across 2 floors: 120 copper lines, 2 comms racks, some routes run through trays with turns and occasional tight bends. Any hidden defect will show early after move: phones drop, printers disappear, speeds fluctuate.

Precise tender wording solves this. If the spec just says “test the SCS,” the contractor may deliver a general report without ties to outlets or proof of testing the exact lines. If you define labeling, test mode, file format and the link to as‑built docs in advance, acceptance becomes verifiable.

A convenient requirement is to deliver a single organized archive instead of a jumble of files: register, tester files (native + PDF), floor plans, rack diagrams, photos.

Also require the contractor to fix all Fail lines and include repeat test reports. In practice failures are usually due to installation: swapped pairs, overtightened zip ties, labeling errors, extra splices, or poorly seated modules.

Acceptance criteria can be simple: 100% of lines have Pass protocols to the declared standard, 100% of lines are present in the register and on drawings, labels match reports in the field, and nonconformities are fixed and re‑verified.

Next steps: how to prepare the specification and organize acceptance

Start with the basics: which services will run on the network and how critical downtime is. This helps choose the right level of checks and acceptance criteria.

Before publishing the tender gather core data: line categories, port counts, cross‑connect composition, fiber requirements (if any), schedule, site access rules, labeling scheme and drawing format. Then include testing and handover requirements as part of the tender docs and the future contract, allowing time for defect correction and retesting.

If you lack internal resources for design and independent acceptance, hire a systems integrator. For example, GSE.kz as a manufacturer and integrator of IT infrastructure in Kazakhstan can assist with design, equipment supply and organizing acceptance against measurable criteria so operations receive a clear documentation package.