Why the project brief matters before SKU selection
Access control is a system, not a product. The same controller and reader combination can be correctly specified for one building and wrong for another depending on door preparation, user volume, credential technology, power source, network ownership, connected systems and local regulations. A supplier quotation issued without a project brief typically generates change orders, site queries and commissioning delays because the assumptions embedded in the quote do not match the actual site.
A project brief makes the scope explicit before the order is placed. It answers the questions that separate a working installation from a list of hardware: Who can access which door under what conditions? What happens when the power fails? Who owns the network the system runs on? Who accepts the installation and who supports it after handover?
Section 1: The door schedule
The door schedule is the foundation of the brief. For each controlled door, record:
- Door identification: number, name, building, floor and location (e.g., Main entrance, Level 2 server room, Car park gate)
- Door type: material, thickness, handing, swing and whether it is fire-rated
- Lock type: electric strike, electromagnetic lock (EM lock), motor lock or electric bolt — and whether the door is fail-safe (opens on power loss) or fail-secure (locks on power loss)
- Reader position: wall-mounted, frame-mounted, door-mounted — and whether there is an exit reader as well as an entry reader
- Cable route: existing cable type and condition at the reader position; power source availability at or near the door
- Controlled area: which user groups can enter, and under which schedule or conditions
Section 2: Users, credentials and access policy
The user and credential design determines which controller database capacity, credential technology and management workflow are required:
- User groups: permanent residents or staff; temporary visitors; contractors; delivery personnel; cleaning and maintenance; administration and security
- Credential technology: MIFARE Classic, MIFARE DESFire EV2/EV3, EM4100, HID iCLASS, NFC mobile, Bluetooth BLE, PIN, biometric (fingerprint, face), or a combination
- User volume: total number of stored credentials the controller database must hold; peak concurrent access (e.g., shift changeover)
- Visitor management: are temporary access codes or escort procedures required? Does the visitor workflow need to be logged?
- Emergency egress: how does the system behave during a fire alarm? Which doors must unlock automatically and which must remain locked? Who can override the system manually?
- Offline behaviour: if the controller loses network connectivity, can users still access doors? What is the maximum time the system should operate in offline mode while storing events for later upload?
Section 3: Infrastructure inputs
The infrastructure section determines whether the proposed system can be installed at the specified locations with the available power, cabling and network:
- Power at each door: is mains power available near the door? If not, is there a cable route to bring it? For EM locks, what is the power draw and which breaker circuit will supply it?
- Cable routes: for a new installation, what is the cable path from each door to the panel? For a retrofit, what existing cable type, gauge and condition is available?
- Controller location: where will the access-control panel be installed? Is there a data closet, server room or security room? What is the cable distance from panel to the furthest door?
- Network owner: who manages the IP network the controller will connect to? What is the VLAN policy? Who can configure firewall rules for cloud connectivity or VMS integration?
- Connected systems: does the project require integration with a video management system (VMS), video intercom, building management system (BMS), PBX/SIP, or a property management platform? List each system, its manufacturer and version.
Section 4: Destination and document requirements
The destination determines certification, language and importer obligations. Record:
- Destination country and market: this determines applicable wireless certifications (CE/RED, FCC, IC, SASO), electrical standards and label requirements
- Documentation language: manuals, labels, declaration of conformity and handover documentation in the required languages
- Project phases: if the project is phased (e.g., building A followed by building B six months later), the phase plan determines whether controllers, licences and cable infrastructure need to be pre-provisioned
- Acceptance criteria: what tests must be passed before the installation is accepted? Who is the acceptance authority?
- Support route: who is the first point of contact for users after handover? What is the response commitment for a door that cannot be opened? Who holds the administrator credentials?
What should an access control project brief contain?
Start with the operating decision, then attach the technical evidence. The same reader or controller can be suitable for one opening and unsuitable for another when door preparation, emergency egress or network ownership changes.
| Input | Record | Why it changes the review |
|---|---|---|
| Opening | Door type, lock body, reader position and controlled area | Defines the mechanical and electrical boundary |
| People | Residents, staff, visitors, contractors and administrators | Defines credentials, permissions and fallback access |
| Infrastructure | Power, cable route, network and existing interfaces | Defines installation and integration work |
| Delivery | Destination, phases, acceptance owner and support route | Defines documents, testing and handover |
Build the brief in a reviewable order
- Map each entrance, controlled door, reader location and door-release method.
- Describe user roles, visitor handling, emergency egress and offline or fallback access.
- Attach power, cable, network and platform details, including any existing intercom, VMS, PBX or property system.
- State the destination, project phases, acceptance criteria, documentation language and first-line support owner.
- Link every requested model to the door and workflow it is meant to serve.
Access control project brief FAQ
Can a supplier quote without a door schedule?
A preliminary discussion can start without a complete door schedule, but a model recommendation and integration review require the openings, user flow and infrastructure constraints. Mark unknown fields clearly so assumptions are visible and do not become hidden scope items in the order.
What is the most important input for a multi-door project?
There is no single universal input. Door conditions, access policy, credential technology, controller topology, power sources and handover ownership must be reviewed together because a change in any one can change the selected system boundary. Projects that fail at commissioning typically have one or more of these fields left undefined until installation is underway.
What should be tested at handover?
Test normal access (each door, each credential type), denied access, emergency release (manual and fire-alarm triggered), power failure recovery, network failure offline behaviour and re-sync, and connected-system event generation (VMS recording, BMS alarm, PBX call routing) on the named configuration. Document the test results and include them in the as-built package.
Which credential technology should be specified?
Choose the credential technology based on security requirements and the existing card infrastructure. MIFARE Classic cards are adequate for low-security commercial applications but are cryptographically weak; MIFARE DESFire EV2/EV3 is the current standard for higher-security applications. If the project integrates with an existing card system, match the credential technology to the cards already in use. Mobile BLE credentials offer convenience but require active device management (app updates, lost-device revocation).
Who should own the administrator credentials after handover?
Assign credential ownership explicitly in the handover record — not to a role or a contractor, but to a named individual or, for large organisations, a named team with a documented escalation path. A common and costly problem is that administrator credentials are held by the installing contractor who has since moved on. Define the process for credential re-issuance and recovery before handover.
Send the door schedule or a project summary for a model, integration and document review.
Start a project review