Electronic Security in Public Buildings: Procurement and Inspection

How to procure electronic security for public buildings: CFTV, access control, integration, ONVIF, LGPD, inspection, commissioning, and acceptance under Law 14.133.

Check it out!

Procuring electronic security for public buildings should not be treated as an isolated purchase of cameras, biometric readers, controllers, or software. The real object is an integrated physical security system comprising sensors, field devices, network infrastructure, servers, storage, management platforms, access rules, integrations, electrical infrastructure, cybersecurity, personal-data processing, operating procedures, and acceptance criteria.

When this systems view is absent from the Preliminary Technical Study, Terms of Reference, design, bidding documents, and inspection plan, the Public Administration transfers to the integrator decisions that should have been made before procurement. The consequences usually emerge during implementation: technically good equipment that does not interoperate, undersized licenses, insufficient storage, doors without local autonomy, limited integrations, analytics that do not achieve the operational purpose, network failures, cybersecurity gaps, conflicts with the LGPD, and disputes about what exactly must be accepted.

In public buildings, complexity increases because the system must simultaneously support asset protection, personal safety, service continuity, traceability, auditing, operation by internal or outsourced teams, administrative rules, data protection, and public-procurement requirements. Therefore, the best result does not begin with a brand or catalog: it begins with the technical definition of the problem, architecture, performance requirements, interfaces, and acceptance evidence.

Why is public electronic security an engineering system rather than an equipment list?

A public building may combine visitor reception, administrative areas, technical rooms, archives, a data center or server room, parking, perimeter areas, loading docks, service areas, restricted-circulation spaces, and sectors with different criticality levels. Each zone imposes different requirements.

A camera that adequately serves a circulation area may be unsuitable for facial identification at an entrance. A biometric reader may identify a person, but the decision to release a door may depend on rules stored in controllers, schedules, groups, anti-passback, alarm status, interlocks, network contingency, and integration with other platforms. A VMS may record video, but operations may require event correlation, maps, investigation, forensic export, audit trails, and integration with access control.

Therefore, procurement must address at least five layers:

Layer	Examples	Engineering question
Field	cameras, readers, sensors, locks, contacts, request-to-exit devices	does the device sense or actuate with adequate performance?
Control	controllers, I/O, gateways, edge devices	does the system continue operating when the server or network fails?
Communication	Ethernet, PoE, VLAN, fiber, Wi-Fi when applicable	is there sufficient capacity, redundancy, segmentation, and security?
Platform	VMS, ACS, PSIM, analytics, database	how are events, rules, users, and evidence managed?
Operation	procedures, profiles, response, maintenance, auditing	can the agency operate, investigate, and maintain the system?

If any of these layers is absent from the scope, the procurement is incomplete. Equipment may be installed, powered, and visible in software without the solution being ready to fulfill the public purpose that justified the investment.

The article on electronic security fundamentals, architecture, and integration explores the technological elements in greater depth. Here, the focus is public procurement and the technical governance required to turn those elements into an object that can be tendered, inspected, and accepted.

Law 14.133 requires technical planning before procurement

Law 14.133 structures the preparatory phase as a planning stage. Article 18 requires consideration of technical, market, and management dimensions capable of affecting the procurement. For electronic security, this means that the Public Administration must understand the need before writing specifications or requesting prices.

The initial question should not be “how many cameras will be purchased?” It should be: which risks and operational needs must the system address, in which areas, with what performance, availability, retention, integration, and evidence?

A consistent ETP should address topics such as:

the security problem motivating the procurement;
current condition of existing systems;
possibility of reusing, integrating, or migrating the installed base;
criticality of areas and assets;
availability and continuity requirements;
need for CFTV, access control, intrusion detection, intercom, LPR, analytics, or PSIM;
impacts on network, servers, storage, power, and cooling;
cybersecurity requirements;
processing of personal and biometric data;
implementation and operating model;
software licensing;
maintenance, updates, and support;
test and acceptance criteria;
vendor lock-in risks;
capacity of the public-sector team to operate and inspect the solution.

The maturity of this stage directly affects the bidding documents. If the ETP merely reproduces an equipment list, the Terms of Reference tend to inherit the same weakness, and procurement begins comparing products without a sufficiently defined architecture.

The most common mistake: specifying a product before defining the operational requirement

In physical security systems, specifications often originate from datasheets. The Public Administration selects a reference camera, server, reader, or platform and turns that product’s characteristics into requirements.

This reverses the logic. First there must be an operational requirement; then, a technical solution capable of meeting it.

Consider an institutional entrance. The purpose may be to identify people entering, associate the event with a credential, record an image with sufficient quality, keep the door secure during communication failure, allow emergency release according to the security strategy, and record every administrative intervention.

This need must be broken down into verifiable requirements. Selection of the sensor, resolution, lens, WDR, illuminator, biometrics, controller, lock, protocol, or server comes afterward.

IEC 62676-4:2025, applicable to video surveillance systems for security applications, reinforces this approach by addressing VSS planning, design, installation, testing, commissioning, and maintenance. The value of such a reference is not to turn bidding documents into a transcription of the standard, but to require the system to be conceived from its purpose and to have objectively verifiable performance.

How can security needs be converted into verifiable requirements?

A useful requirement must make three things possible: specify, compare, and test.

“High-resolution camera” is weak because it does not define a result. “4 MP camera” is more objective, but it still does not demonstrate that the system will fulfill its purpose. Resolution is only one component of the image chain.

A more mature structure connects:

risk → operational objective → scenario → functional requirement → performance requirement → test evidence → acceptance criterion.

Example:

Element	Definition
Risk	unauthorized access to a technical area
Objective	prevent entry by a person without valid authorization
Scenario	user presents a facial credential or card at the door
Function	identify, validate the rule, and grant or deny access
Performance	decision within the established time and local continuity according to requirements
Evidence	logs, system event, physical door actuation, and contingency test
Acceptance	all scenarios approved according to a documented procedure

This chain is decisive during inspection. If the Public Administration contracts only product characteristics, the inspector can verify whether the installed model matches the proposal but may be unable to demonstrate whether the security objective was achieved.

How should the architecture be defined before procurement?

The architecture should describe relationships among subsystems, zones, networks, platforms, and responsibilities. It need not freeze every manufacturer-specific detail when the contracting model allows later development, but it must establish the boundaries that cannot remain open.

For IP CFTV, the architecture should normally define:

network topology and segmentation;
recording location;
physical or virtual servers, or appliances;
storage and retention policy;
continuous, event-based, or hybrid recording;
permitted codecs;
analytics and metadata handling;
operator workstations;
user profiles;
evidence export and preservation;
time synchronization;
integration with access control and other systems;
required redundancy;
configuration backup;
update and firmware policy.

For access control, consideration should be given to:

server-controller-reader architecture;
where access rules are actually executed;
behavior during loss of communication;
controller capacity and memory;
protocols between reader and controller;
credential types;
anti-passback and occupancy rules;
interlocks;
integration with alarms and video;
emergency commands;
power supply and autonomy;
event recording;
identity administration;
migration of existing records.

This care avoids a recurring problem: confusing the identification device with the component that makes the access decision. In robust architectures, readers, biometric terminals, controllers, and servers may divide functions. The bidding documents must establish the responsibility of each layer and the expected behavior in normal, degraded, and contingency modes.

The article on corporate access-control architecture helps explain this separation between identity, decision, door control, and central management.

Interoperability must be specified by function, not by the word “ONVIF”

Interoperability is one of the highest-risk issues in electronic-security procurement. The phrase “ONVIF-compatible equipment” is insufficient because ONVIF does not represent a single universal function.

The organization maintains distinct profiles for specific feature sets. For video, Profile T covers advanced streaming and functions such as H.264/H.265, image configuration, events, metadata, and, where supported, additional capabilities. For access control, Profiles A, C, and D support different sets of configuration, door control, events, and peripheral functions.

ONVIF itself warns that only products officially registered as conformant with a profile should be treated as ONVIF conformant. This must be reflected in technical due diligence: a commercial statement in a datasheet is not enough.

There is also an important current point. In October 2025, ONVIF announced the end of support for Profile S and recommended Profile T as its successor for video applications. A public specification that simply repeats “ONVIF Profile S” from older bidding documents may freeze an outdated technological reference, including authentication mechanisms that the organization itself considers incompatible with current cybersecurity recommendations.

To avoid this, the bidding documents should define:

which function must interoperate;
which profile or interface supports that function;
which versions or minimum conditions are accepted;
how product conformity will be verified;
which test will demonstrate actual integration;
which features may remain proprietary;
which integrations are mandatory for acceptance.

This method reduces the risk of “partial compatibility,” where video appears in the VMS but events, analytics, PTZ, audio, I/O, edge recording, metadata, or administration features do not work as expected.

Integration among CFTV, access control, and PSIM requires use cases

An integrated system is not one that merely displays several interfaces on the same monitor. Useful integration must produce operational behavior.

Examples of use cases:

an access-denied event automatically opens the corresponding camera;
a forced door generates an alarm, video, and correlated record;
an operator retrieves video associated with a credential event;
a perimeter alarm presents a map, video, and response procedure;
an analytics event creates an operational incident;
license-plate recognition is associated with vehicle access authorization;
loss of controller communication generates a system-health alarm;
recording or storage failure triggers a technical alert;
critical events are forwarded to the PSIM with priority and workflow.

Each case must identify the event source, destination, exchanged fields, acceptable latency, failure behavior, records, responsibility, and test criterion.

The PSIM — Physical Security Information Management solution is especially relevant when the Public Administration needs to coordinate multiple subsystems and procedures. But not every building requires PSIM. The requirement should derive from operational complexity, not from the desire to add another software layer.

Bidding documents should avoid vendor lock-in without sacrificing performance

Public procurement of electronic security must balance two concerns: interoperability and technical accountability.

An excessively proprietary specification may restrict competition and create manufacturer dependence. On the other hand, requiring generic interfaces without defining performance can produce a solution that is formally “open” but functionally limited.

The appropriate strategy is to separate:

performance requirements;
mandatory open interfaces;
functions that may remain proprietary;
integrations that must be certified or approved;
data that must be exportable;
backup and recovery formats;
license use and continuity rights;
API documentation when applicable;
conditions for future component replacement.

This is particularly important for VMS, access-control systems, and analytics platforms because selecting a platform creates life-cycle effects far greater than acquiring an individual camera.

How can CFTV be sized without turning megapixels into a design criterion?

Resolution cannot be analyzed in isolation. The design must relate scene, distance, lens, field of view, lighting, motion, compression, image quality, identification purpose, and storage capacity.

At an entrance, the purpose may require identification. In a parking area, operations may require license-plate recognition. In a corridor, detection and tracking may be sufficient. At a perimeter, the priority may be reliable detection and intrusion alarms.

An IP CFTV and Video Surveillance Design should convert those purposes into coverage, positioning, specifications, VMS, storage, network, integration, and tests.

The bidding documents should also require design evidence: coverage drawings, calculation reports, bitrate and retention assumptions, camera schedules, network architecture, integration matrix, and acceptance criteria.

Storage must be calculated using explicit assumptions

Storage is one of the items most subject to differences among manufacturer calculators. The result depends on resolution, frame rate, codec, GOP, scene complexity, lighting, motion, VBR/CBR, event-based recording, retention, and proprietary compression features.

Therefore, estimates and proposals must make the assumptions explicit. It is not technically appropriate to compare two storage solutions only by raw capacity in TB.

Sizing must distinguish:

raw and usable capacity;
RAID overhead or equivalent protection;
target retention;
operating margin;
design bitrate;
continuous and event-based recording;
primary and secondary streams;
analytics and metadata;
exported evidence;
future expansion;
disk-replacement policy.

During inspection, these assumptions must be verified against the configuration actually implemented. A system delivered with a bitrate far below that used in the sizing calculation may achieve contractual retention by sacrificing image quality.

Access control must be tested in degraded mode

A system may work perfectly while servers, controllers, network, and power are available. That does not demonstrate resilience.

The test plan should include loss of communication between controller and server, restart, power failure, battery operation, behavior of critical doors, event preservation, later synchronization, operation of emergency devices, and recovery after failure.

Business scenarios should also be tested:

Scenario	Expected result
valid credential	access granted according to rule
invalid credential	access denied and event recorded
access outside allowed hours	rule applied correctly
door held open	alarm generated
forced door	alarm and video correlation
server loss	local behavior according to requirement
communication restored	events synchronized and system normalized
emergency	doors operate according to the security strategy and applicable legislation

The existence of a facial terminal does not eliminate the need to understand where credentials, rules, and decisions reside. Depending on the architecture, validation may occur at the device, controller, or central layer, and this design affects performance, availability, and security.

Biometrics requires specific LGPD treatment and governance

The LGPD classifies biometric data linked to an individual as sensitive personal data. This makes the procurement of facial recognition, fingerprints, iris recognition, or other biometrics different from a simple hardware purchase.

The agency must define purpose, legal basis, necessity, proportionality, retention, security, access, sharing, record of processing activities, and responsibilities between controller and processors. The design should avoid excessive collection and clearly separate biometric templates, images, credentials, and logs when the architecture permits.

ANPD has been treating biometrics as a highly relevant regulatory topic. Recent technical documents highlight the potential impact of facial recognition and other biometric technologies on fundamental rights and the need to comply with LGPD principles and legal bases.

For bidding documents, this translates into practical questions:

where are biometric templates stored?
will the manufacturer or integrator have remote access?
will data be sent to the cloud?
is processing performed outside Brazil?
what is the retention policy?
how is a user deleted?
how are backups protected?
which logs record queries and changes?
is there segregation of administrative profiles?
how are software updates performed without unnecessary data exposure?

The assessment should be proportional to context. Biometrics in a mission-critical area is not necessarily inappropriate; however, its adoption must be technically justified and governed.

Cybersecurity has become a physical-system requirement

Cameras, controllers, intercom devices, servers, and appliances are IP assets. A connected physical-security architecture without proper hardening creates a new attack surface.

The design should address:

network segmentation;
VLANs and ACLs;
authentication and credential management;
disabling default accounts;
HTTPS/TLS when supported;
certificates;
SNMP and monitoring;
secure NTP and time synchronization;
firmware updates;
version inventory;
configuration backup;
remote access;
logs and auditing;
unnecessary ports and services;
vulnerability management;
life cycle and end of support.

This is another reason not to copy old specifications. ONVIF’s 2025 Profile S announcement is an objective example of how interoperability criteria also evolve for cybersecurity reasons.

How should technical qualification be structured without steering procurement?

Qualification should demonstrate capacity compatible with the complexity of the object without turning a technological preference into an undue barrier.

In integrated electronic security, the Public Administration may need to verify experience in relevant portions such as:

design or implementation of IP CFTV;
VMS at a compatible scale;
access control;
integration among subsystems;
associated networks and storage;
systems in critical operating environments;
commissioning and integrated testing.

The relevance of each portion depends on the specific object. A procurement focused primarily on access control should not require disproportionate experience with video walls, for example.

Team qualification must also reflect actual responsibilities. Multidisciplinary projects may require engineering coordination and specialists in electronic security, networks, electrical systems, cybersecurity, and commissioning.

How should technical proposals be compared beyond price?

Two proposals may present the same quantities and similar prices while assuming profoundly different architectures.

The technical analysis should compare:

Dimension	What to verify
Architecture	compliance with the design and interfaces
Equipment	full compliance with requirements
Licenses	quantity, model, validity, and features
Integrations	native, protocol-based, API-based, or custom development
Storage	assumptions, usable capacity, and retention
Network	ports, PoE, uplinks, redundancy, and segmentation
Servers	processing, memory, GPU when required, and expansion
Cybersecurity	hardening, updates, and vulnerability management
Migration	preservation of records, configurations, and history when applicable
Tests	procedures, instruments, evidence, and acceptance
Support	SLA, escalation, manufacturer, and integrator
Life cycle	discontinuation, compatibility, and future expansion

This analysis reduces the risk of contracting the apparently lowest-priced proposal and later discovering that essential items were treated as options, extras, or outside the scope.

A3A also provides Technical Support for Procurement and Engineering Proposal Analysis, which is especially useful when the evaluation committee needs specialized support to verify architecture, technical compliance, and differences among proposals.

Why is reviewing the bidding documents before publication cheaper than correcting implementation?

Most electronic-security problems that appear during implementation were already latent in the bidding documents: integration without a use case, storage without assumptions, ONVIF without a profile, undefined licenses, and acceptance without a test procedure. An independent technical review before publication allows these gaps to be corrected while they are still inexpensive to resolve.

Learn about Technical Review of Bidding Documents and Attachments for Engineering Procurement

A large share of execution conflicts originates in ambiguities that predate the contract.

Examples:

the bidding documents require integration but do not list events and commands;
retention is stated in days without recording assumptions;
the specification requires biometrics but does not define architecture and data processing;
VMS is required without quantifying licenses;
storage is defined only in TB;
the server is described without a workload;
ONVIF is mentioned without profile or function;
the system must be “redundant,” but the supported failure is not defined;
acceptance is conditioned on “operation” without a test procedure;
migration of the installed base has no defined responsibility.

The Technical Review of Bidding Documents and Attachments should verify consistency among the ETP, Terms of Reference, design, quantities, estimate, qualification, evaluation, risk matrix, measurement, inspection, and acceptance.

In electronic security, the review must also identify cross-discipline incompatibilities. It is not enough for each discipline to be correct in isolation. A camera may meet its datasheet but exceed the PoE capacity of the specified switch. A set of readers may work but exceed controller capacity or topology. Storage may meet calculated volume while the network cannot support aggregate traffic.

How should electronic-security implementation be inspected?

Inspecting electronic security requires more than checking installed quantities. Configurations, integrations, licenses, events, logs, storage, contingencies, and performance must be converted into technical evidence that supports the inspector formally designated by the Public Administration.

See how Technical Support for Inspection of Engineering Works and Contracts operates

Article 117 of Law 14.133 establishes monitoring and inspection of contract execution and requires occurrences to be recorded. For electronic systems, inspection should combine physical inspection, document verification, configuration testing, and digital evidence.

Evidence-based inspection is especially suitable because many requirements cannot be demonstrated by a photograph.

An installed camera may require evidence of:

model and serial number;
firmware;
stream configuration;
codec and bitrate;
NTP;
resolution and frame rate;
VLAN and address;
VMS integration;
recording;
analytics;
coverage and image quality;
tamper alarms when applicable.

An access-control door may require:

reader and credential method;
associated controller;
logical address;
power supply;
battery;
lock;
door sensor;
request-to-exit device;
access rule;
events;
communication-failure test;
video integration;
emergency behavior.

The public-works inspection method can be applied to electronic systems through baseline control, inspection, nonconformity records, measurement, and progressive acceptance.

Inspection must follow detailed design and submittals

In many contracts, the procurement design does not contain every installation detail. The contractor develops detailed design, shop drawings, diagrams, point lists, final architecture, calculations, and manufacturer documentation.

These documents should not be treated as mere paperwork. They are the opportunity to verify the solution before errors become physical installation.

The workflow should define:

required documents;
responsible authors;
submission deadlines;
review criteria;
status codes;
comment process;
condition for releasing installation;
revision control;
As-Built updating.

Installing before critical documents are approved transfers the agency’s technical control to the field and increases the probability of rework.

Measurement should pay for verifiable delivery, not merely delivered equipment

Electronic security is particularly vulnerable to early measurement because much of the value is concentrated in equipment.

If the contract recognizes almost all value upon physical delivery, the Public Administration loses leverage to require integration, configuration, documentation, training, testing, and corrections.

A measurement structure can separate milestones such as:

approval of detailed design;
supply and inspection;
physical installation;
configuration;
integration;
functional tests;
contingency tests;
As-Built documentation;
training;
commissioning;
provisional acceptance;
correction of open items;
final acceptance.

The Construction Measurement Report presents the logic of linking payment to evidence and measurement criteria.

What should be included in the testing and commissioning plan?

The test plan should be developed before implementation is complete. Testing only at the end creates a queue of defects when schedule and budget are already under pressure.

IEC 62676-4:2025 includes testing and commissioning in the video-surveillance system life cycle. For an integrated solution, the plan should extend this logic to all subsystems.

A mature strategy combines verification levels:

Document verification

Checks models, licenses, designs, point lists, firmware, versions, certificates, backups, network documentation, and manuals.

Physical inspection

Verifies installation, mounting, orientation, identification, finish, infrastructure, power supply, protection, grounding when applicable, and conformity with drawings.

Functional test

Demonstrates each individual function: video, recording, access, alarm, relay, sensor, audio, analytics, LPR, or another contracted function.

Integration test

Demonstrates exchange of events and commands among platforms.

Failure test

Simulates loss of server, network, power, storage, controller, link, or another critical component according to the architecture.

Performance test

Verifies retention, image quality, latency, throughput, search capacity, number of streams, analytics response, or other defined indicators.

Operational test

Validates real procedures with operators, user profiles, investigation, evidence export, alarms, and response.

IEC 62676-2-11:2024 is particularly relevant to government environments because it defines minimum interoperability profiles between VMS and cloud systems, including authority-access scenarios. It shows how video interoperability can be specified at functional levels rather than only as generic compatibility.

Acceptance must be based on a requirements-and-evidence matrix

Acceptance should not begin with an equipment list. It should begin with the requirements matrix.

A traceability matrix may contain:

ID	Requirement	Source document	Verification method	Evidence	Result
SEC-001	minimum video retention	TR	analysis + test	storage report	pass/fail
SEC-002	forced-door event correlated with video	design	integrated test	log + capture	pass/fail
SEC-003	local operation during server loss	design	failure test	test record	pass/fail
SEC-004	evidence export with audit trail	TR	functional test	file + log	pass/fail
SEC-005	segregation of administrative profiles	security policy	configuration inspection	user matrix	pass/fail

This model reduces subjectivity. Instead of asking “is it working?”, the inspector verifies whether each contracted requirement has sufficient evidence.

Commissioning is different from the integrator’s configuration work

The company that installs the system naturally performs configuration and internal tests. That does not replace a structured verification from the owner’s perspective.

Commissioning should verify whether the system as a whole meets the requirements and is ready for operation. This involves technical independence, test planning, result records, open-item control, retesting, and acceptance documentation.

In complex systems, commissioning can identify failures that do not appear during physical inspection:

events that do not reach the VMS;
different time zones or NTP settings;
an access rule not replicated to the controller;
failover that does not occur;
a camera that loses analytics when using a particular codec;
storage that cannot sustain the real load;
a temporary or incomplete license;
integration that works only in a specific scenario;
a user with excessive privileges;
a backup that exists but cannot be restored;
a contingency procedure that cannot actually be executed.

Engineering Commissioning structures verification, testing, readiness, and handover with a focus on a deliverable that the owner can actually use.

How should migration of existing systems be handled?

Modernization in public buildings rarely starts from zero. There may be an installed base of cameras, readers, controllers, credentials, servers, cables, switches, racks, and licenses.

The ETP should decide what will be:

retained;
integrated;
updated;
migrated;
replaced;
decommissioned.

Migration must have inventory, compatibility, responsibility, and an operating window. In access control, it is essential to define how users, groups, credentials, history, biometric templates, and rules will be handled. In VMS, existing recordings, servers, storage, licenses, and continuity of monitoring during the transition must be assessed.

An inadequate strategy can create two parallel systems for months, duplicate operations, or create a security window during cutover.

How can discontinuation and technology-dependence risks be reduced?

The life cycle of electronic security is longer than the commercial life cycle of many products. Cameras, servers, and software may be discontinued while the building continues to operate.

The contract should address:

manufacturer support period;
update policy;
spare-parts availability;
minimum supported version;
operating-system compatibility;
software update rights;
license transfer;
replacement by successor models;
data export;
documentation and administrative passwords;
termination of the integrator’s remote access.

The Public Administration should not receive a solution that is technically closed, works on day one, and is impossible to maintain in year three.

What evidence should be included in the As Built?

The electronic-security As Built must represent the actual system, not merely update drawings.

Depending on scope, the final package should include:

drawings showing device locations and identifiers;
network diagrams;
access-control diagrams;
IP address table;
VLANs and ports;
camera list;
door list;
serial numbers;
models and firmware;
servers and storage;
licenses;
electrical diagrams;
cable and termination list;
integration matrix;
user and profile matrix in a secure format;
configuration backups;
restoration procedures;
test reports;
closed open items;
manuals and warranties;
training records.

The documentation must be sufficient for another qualified professional to understand, maintain, and evolve the system without depending exclusively on informal knowledge held by the original integrator.

Who should participate in inspection?

Law 14.133 allows the Public Administration to contract third parties to assist and support inspectors with technical information without transferring the public agent’s own responsibility. Decree 11.246/2022, within the federal scope to which it applies, details the roles of managers and inspectors and recognizes inspection complexity as an element to consider in appointment.

In an integrated security system, the public-sector team may not internally possess all the competencies needed to review VMS, networks, access control, storage, cybersecurity, licensing, and commissioning.

Technical Support for Inspection of Engineering Works and Contracts can provide inspections, document analysis, tests, records, and technical opinions that support the formally designated inspector.

This separation is important: technical consulting does not replace the inspector’s legal role. It improves the quality of the information available for the inspector’s decision.

How can procurement be structured in stages?

A large procurement can be organized into technical gates.

Gate	Condition to advance
G0 — diagnosis	inventory and risks known
G1 — requirements	objectives, architecture, and criteria approved
G2 — procurement	bidding documents and attachments technically consistent
G3 — detailed design	submittals and drawings approved
G4 — installation	infrastructure and devices verified
G5 — configuration	platform and rules configured
G6 — integration	integrated use cases approved
G7 — commissioning	functional, failure, and performance tests approved
G8 — handover	documentation, training, and backups complete
G9 — acceptance	open items closed and formal acceptance completed

This model prevents the schedule from being treated as a purely physical sequence. Installation advances when the engineering required for that stage is mature.

Technical checklist for electronic-security bidding documents

Before publication, it is worth checking whether the documents clearly answer the following questions:

Need and scope

which risks and objectives justify the procurement?
which buildings, areas, and systems are included?
is there an installed base to preserve?
which interfaces are outside the scope?

Architecture

where are servers, controllers, and storage located?
is there redundancy? of what, and against which failure?
how do subsystems communicate?
what is the network topology?
how does the system operate during communication loss?

CFTV

what is the purpose of each camera?
is there a coverage study?
how was storage calculated?
which codecs and streams will be used?
which analytics are mandatory?

Access control

where is the access decision made?
which credentials are accepted?
what is the offline behavior?
how are emergency doors handled?
which integrations are required?

Software and licensing

which modules and license quantities are required?
are they perpetual, subscription-based, or term licenses?
is there recurring cost?
which updates are included?

Interoperability

which functions must be interoperable?
which ONVIF profile applies?
how will conformity be demonstrated?
which APIs or SDKs are required?

Cybersecurity and LGPD

how will credentials and access be managed?
are there hardening requirements?
how will biometric data be handled?
is there supplier remote access?
which logs and audit trails are mandatory?

Inspection and acceptance

which documents must be submitted?
which tests will be performed?
which evidence will be required?
how will nonconformities be handled?
what defines provisional and final acceptance?

If several answers depend on future decisions by the integrator, the object is not yet sufficiently mature for competitive and technically controlled procurement.

When does it make sense to contract Consulting Engineering before procurement?

Specialized support is especially relevant when the agency:

has legacy systems from different manufacturers;
plans to migrate VMS or access control;
will use biometrics or facial recognition;
has multiple buildings;
needs to integrate CFTV, access, intrusion detection, and PSIM;
has high-availability requirements;
needs to preserve operations during implementation;
does not have an internal team able to review the architecture;
plans significant investment with a long life cycle;
needs to prepare an ETP, Terms of Reference, design, or bidding documents;
will receive technically heterogeneous proposals;
requires independent inspection, commissioning, or acceptance.

In this scenario, Consulting Engineering acts before the purchase, during selection, and throughout execution. Its role is not to choose a brand for the agency, but to organize requirements, reduce technical information asymmetry, make proposals comparable, and create evidence for decision-making and acceptance.

Final considerations

Electronic security in a public building is an engineering and technology procurement with a strong operational component. The risk of failure increases when the Public Administration attempts to simplify it into a list of cameras, readers, servers, and licenses.

The quality of the result depends on a coherent sequence: diagnosis, requirements, architecture, design, bidding documents, proposal analysis, inspection, testing, commissioning, and acceptance. Each phase must preserve traceability between the problem that motivated the investment and the evidence that will demonstrate compliance.

Interoperability must be verified by function; ONVIF needs to be specified by profile and actual conformity; storage must be sized with explicit assumptions; access control must be tested under failure; biometrics requires data governance; cybersecurity must be part of the architecture; and acceptance must verify the integrated system under operational scenarios, not merely the physical installation.

When the Public Administration structures these elements before procurement, it increases competition on technically comparable grounds, reduces change orders and interpretation disputes, and preserves its ability to inspect and evolve the solution throughout the life cycle.

An installed system is not the same as a ready system. Commissioning organizes functional tests, integrations, failures, performance, documentation, open items, and retesting so that acceptance is based on demonstrated requirements — not merely on the perception that the equipment is powered on.

Learn about Engineering Commissioning

Technical references

[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021 — Lei de Licitações e Contratos Administrativos. 2021. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.

[2] BRASIL. Decreto nº 11.246, de 27 de outubro de 2022 — atuação dos gestores e fiscais de contratos. 2022. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2022/decreto/d11246.htm.

[3] BRASIL. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais (LGPD). 2018. Available at: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm.

[4] AUTORIDADE NACIONAL DE PROTEÇÃO DE DADOS. Documentos Técnicos e Orientativos — tratamento de dados pessoais e biométricos. 2026. Available at: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos.

[5] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-4:2025 — Video surveillance systems for use in security applications — Part 4: Application guidelines. 2025. Available at: https://webstore.iec.ch/en/publication/110108.

[6] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-2-11:2024 — Interop profiles for VMS and cloud VSaaS systems for safe cities and law enforcement. 2024. Available at: https://webstore.iec.ch/en/publication/66755.

[7] ONVIF. ONVIF Profiles — video and access control interoperability profiles. 2026. Available at: https://www.onvif.org/profiles/.

[8] ONVIF. Profile T — advanced video streaming. 2026. Available at: https://www.onvif.org/profiles/profile-t/.

[9] ONVIF. ONVIF to End Support for Profile S; Recommends Profile T as Replacement. 2025. Available at: https://www.onvif.org/pressrelease/onvif-to-end-support-for-profile-s/.

Frequently asked questions

Should electronic security in a public building be procured as an equipment purchase?

Not necessarily. In integrated solutions, the object includes architecture, network, software, licensing, storage, access control, integrations, cybersecurity, testing, and documentation. Procurement should reflect the system’s real complexity and the outcomes that must be delivered.

What should be defined before procuring CFTV and access control?

Risks, operational objectives, areas, architecture, functional and performance requirements, integrations, licensing, infrastructure, cybersecurity, data processing, measurement criteria, testing, and acceptance should be defined.

Is it enough to require cameras to be ONVIF?

No. ONVIF has different profiles, each covering specific functions. The bidding documents should identify the required interoperability function, the applicable profile, and how conformity and integration will be tested.

Should Profile S still be used as the main video requirement?

ONVIF announced in 2025 that support for Profile S would end and recommends Profile T as its successor for video applications. New bidding documents should review old references and specify current profiles compatible with the required functions.

How does the LGPD affect facial-recognition and biometric systems?

Biometric data linked to an individual is sensitive personal data. The agency must define purpose, legal basis, security, retention, access, responsibilities, and other controls applicable to processing this data.

How should an electronic-security installation be inspected?

Inspection should combine physical inspections, analysis of designs and submittals, equipment verification, configuration validation, functional and integration tests, nonconformity records, evidence-based measurements, and document control.

What should be tested in access control?

In addition to valid and invalid credentials, schedules, door events, rules, video integration, loss of communication, power failure, autonomy, event synchronization, and emergency behavior according to the design should be evaluated.

What is the role of commissioning in electronic security?

Commissioning systematically verifies that the integrated system meets requirements and is ready to operate. It includes functional, integration, failure, and performance tests, documentation, open-item control, retesting, and support for handover and acceptance.

Can the Public Administration contract technical support to assist the inspector?

Yes. Article 117 of Law 14.133 allows third parties to be contracted to assist and support inspectors with technical information. The inspector’s legal role remains with the representative formally designated by the Public Administration.

Supplementary technical materials