PSAP common mistakes
PSAP · Understand the traps and how to avoid them.
Treating risk assessment as a qualitative gut-feel exercise and skipping the formal steps of asset identification, threat/vulnerability pairing, likelihood and consequence scoring, and documented risk treatment options (accept, mitigate, transfer, avoid).
Candidates come from hands-on installation or guard backgrounds where risk is judged intuitively; exam items reward a structured, repeatable methodology and the vocabulary of risk registers and treatment plans.
What to do instead
Memorize a defensible sequence-identify assets, identify threats, identify vulnerabilities, assess likelihood and impact, calculate risk, select treatment, document residual risk-and practice writing a short risk statement for a hypothetical facility using that sequence and its terminology.
Confusing authentication factors and credential categories, for example labeling a PIN as 'something you have' or treating a proximity card alone as multi-factor authentication.
Everyday language blurs the distinction between a card, a code, and a biometric; exam items deliberately test the three-factor model and the difference between single-factor, two-factor, and layered-but-single-factor designs.
What to do instead
Drill the mapping: something you have (card, fob, phone), something you know (PIN, password), something you are (fingerprint, iris). Then classify combinations-card plus PIN is two-factor; two cards is not-and be able to explain why a card plus a biometric reader at the same door is stronger than two card readers.
Designing PACS architecture without distinguishing the roles of the host server, field controllers, reader interface modules, and the credential database, or assuming the head-end must be online for every door decision.
Candidates memorize product names rather than the functional hierarchy, so they cannot answer questions about degraded mode, distributed intelligence, or where access decisions are actually made.
What to do instead
Draw the architecture from memory: credential → reader → controller/panel → host. State which layer stores the access rules, which layer makes the grant/deny decision when the network is down, and what happens to audit logs during an outage. Repeat until the offline-behavior question is automatic.
Specifying a lock without matching it to the door, frame, traffic, and life-safety requirements-for example putting a standard electric strike on a fire-rated stairwell door or ignoring fail-safe versus fail-secure implications for egress.
Hardware questions look like catalog recall, so candidates pick the most familiar product instead of reasoning from door type, rating, usage frequency, and code-driven egress requirements.
What to do instead
Build a decision checklist you apply to every hardware item: door material and rating, frame type, traffic volume, whether free egress must be preserved, power failure state, and monitoring needs. Practice choosing among strike, electric latch retraction, maglock, and electric bolt by walking the checklist aloud.
Treating the PACS as an isolated system and omitting it from the cybersecurity scope-no mention of network segmentation, default credentials, firmware patching, encryption of controller traffic, or vendor remote-access controls.
Physical security practitioners often view the PACS as 'just door hardware' and defer to IT, so they miss items that test convergence of physical and cyber risk.
What to do instead
For any design scenario, add a cyber overlay: place controllers on a segmented VLAN, change default passwords, require signed firmware and a patch cadence, encrypt management traffic, and document third-party access. Memorize this overlay as a standard paragraph you can apply to any topology question.
Answering alarm-handling questions by describing monitoring technology instead of the operational procedure-failing to state verification, escalation, response dispatch, and documentation as distinct steps.
Candidates know the hardware and software but have not internalized the workflow that turns an alarm into a documented incident, so their answers stop at 'the alarm notifies the operator.'
What to do instead
Learn the alarm lifecycle as a fixed sequence: detect, annunciate, verify (video or secondary sensor), classify, dispatch or escalate per procedure, resolve, and document. Practice narrating a full incident from forced-door alarm to closed report, naming the decision at each step.
Ignoring privacy and data-protection obligations when designing credential and biometric systems-no retention limits, no consent or notice, no role-based access to badge and video data, no consideration of biometric template protection.
Privacy is treated as a legal afterthought rather than a design input, and candidates underestimate how often exam items test data minimization and biometric-specific rules.
What to do instead
Attach a privacy checklist to every identity-verification design: what data is collected, why, how long it is kept, who can see it, how it is secured, and how it is deleted. Know that biometric templates should be protected and that video and badge records are personal data subject to access and retention controls.
Misapplying life-safety and egress code logic-for example assuming a maglock is acceptable on any door, or forgetting that access-controlled egress doors require a compliant release device and often a request-to-exit sensor.
Code questions mix fire, building, and accessibility requirements, and candidates memorize isolated facts instead of the underlying principle that egress must never depend on a credential or a functioning network.
What to do instead
Anchor on the principle: free egress at all times, release on fire alarm where required, and approved exit hardware. Then learn the common exceptions and conditions attached to electromagnetic locks, and verify against the locally adopted code edition rather than a single remembered rule.
Confusing identification with verification (or authentication) and misstating what a credential proves-treating a badge as proof of identity rather than a token that must be bound to a verified identity.
The terms are used loosely in the field, so candidates cannot answer items about enrollment, identity proofing, and the trust chain from vetting to issued credential.
What to do instead
Define the chain explicitly: identity proofing establishes who the person is, enrollment binds that identity to a credential, issuance transfers the credential, and authentication verifies the credential at the door. Be able to say where each step can fail and what controls (photo verification, dual enrollment, revocation) mitigate it.
Skipping commissioning and acceptance testing in installation answers-no as-built documentation, no point-to-point verification, no functional test of fail-safe behavior, no training or turnover records.
Candidates focus on getting the system running and treat closeout as paperwork, but exam items test whether the design is verifiable and maintainable after handover.
What to do instead
Memorize a closeout package: as-builts, device schedules, addressing and programming records, test results for every door and alarm point, fail-safe and fail-secure verification, cybersecurity hardening confirmation, operator training, and warranty documentation. Practice listing these for a sample project.