PSP common mistakes
PSP · Understand the traps and how to avoid them.
Answers a scenario asking for the 'first step' in addressing a newly identified threat by naming a countermeasure (adding cameras, bollards, or a guard post) instead of an assessment activity.
Practitioners with operational backgrounds pattern-match to hardware they have already deployed, and exam items deliberately include plausible hardware answers that skip the assessment stage entirely.
What to do instead
Before selecting anything, test whether the scenario has produced evaluated threat, vulnerability, and consequence inputs. If it has not, the correct first step is an assessment activity - asset inventory, threat assessment, vulnerability assessment, or a documented risk analysis - and the answer should name that activity.
Compiles a list of observed weaknesses, labels the document a risk assessment, and then ranks the items by how serious they feel rather than by a defined combination of threat, vulnerability, and consequence.
The words vulnerability and risk are used interchangeably in day-to-day work, and many assessment tools output a flat findings list with no scoring model behind it.
What to do instead
State the risk model explicitly before analysis (risk as a function of threat likelihood, vulnerability, and consequence), assign a defensible rating to each factor for every finding, and let the computed result drive prioritization. Be able to say which factor a specific finding raises or lowers.
Runs an assessment without documenting scope, assumptions, or the design basis threat, and then cannot answer an item about what level of adversary the protection system was supposed to defeat.
The design basis threat is a narrow, easily-overlooked concept, and on real projects it usually stays implicit in the owner's head rather than being written down.
What to do instead
Anchor every assessment to a written scope and a stated design basis threat - the adversary type, capability, and tactics the system must be designed against - agreed with the asset owner and revisited when the threat picture changes. Note explicitly what is out of scope.
Uses 'detection' and 'assessment' interchangeably, for example treating a camera system as the detection layer or assuming that an alarm annunciating at a console has already been assessed.
Vendor literature and everyday speech both say cameras 'detect,' while the exam keeps detection and assessment as separate functions in the detect–assess–respond sequence.
What to do instead
Keep the functions distinct: a sensor detects an intrusion, a separate means (video review, a guard, a second sensor) assesses whether it is real and what it is, and a response force acts on that assessment. For any proposed design, name the specific device or procedure performing each of the three functions.
Selects cameras, sensors, or lighting from a feature list and price - '4K', 'IR', 'AI-enabled' - without computing performance against the actual target: no pixel density at the identified zone, no consideration of scene illumination or contrast, no stated detection probability.
Datasheets and marketing lead with headline specifications, whereas demonstrating adequate performance requires calculation and knowledge of field conditions.
What to do instead
Convert requirements into measurable criteria before selecting products: pixels per unit of target size at each zone for detect, recognize, and identify tasks; lux and contrast levels at the scene; sensor detection probability and nuisance-alarm rate. Then match candidate devices to those numbers rather than to marketing claims.
Proposes a single control - one fence line, one camera, one guard post - for a high-value asset and treats the problem as solved.
Budget limits and simplicity push toward point solutions, and layered design demands deliberately redundant, independent measures that cost more and take more thought to justify.
What to do instead
Design in depth: multiple independent layers so that an adversary must defeat each in sequence, and check that no single common failure (one power feed, one network switch, one guard on shift) collapses several layers at once.
Specifies fail-secure locking, or a key-operated exit, on a door that sits on a required means of egress, or proposes locking down a door that is on the life-safety egress path.
The security instinct is that 'locked is safer,' and scenarios often describe a theft or unauthorized-entry problem in a space that also has a code-mandated exit.
What to do instead
Apply the life-safety hierarchy first: egress must be free and must not require a key, tool, or special knowledge, and hardware on egress doors releases on fire alarm. Confine hardening to openings that are not on the egress path, and verify against the applicable life-safety code and local authority.
Accepts an installed system because devices power up and the contract term has ended, with no functional performance test, no as-built documentation, and no operator training.
Schedule and payment pressure make commissioning the step most often compressed or skipped, and 'it works when I look at it' feels like verification.
What to do instead
Require a written commissioning and acceptance test plan tied to the design's measurable performance criteria, executed and witnessed before final payment, with as-built drawings, configuration and password records, training records, and warranty start dates delivered as contractual closeout items.
Writes a procurement specification that names a single manufacturer's model, or that states goals ('high-quality video coverage', 'secure the perimeter') instead of measurable requirements, so proposals cannot be compared or held to anything.
Copying a previous specification or a favored vendor's proposal is fast and feels low-risk, and vague language appears to preserve flexibility during negotiation.
What to do instead
Write brand-neutral, performance-based requirements with measurable criteria and 'or equal' language, and attach an explicit deliverables list plus acceptance criteria so every proposal is evaluated against the same yardstick and non-conforming work can be rejected on stated grounds.
Awards on lowest bid price alone and ignores total cost of ownership - maintenance contracts, software licensing and renewals, spares, training, and end-of-life replacement - then cannot justify a lifecycle-cost line in an evaluation item.
Purchase price is the figure budget authority approves, and lifecycle analysis is extra work that bidders are rarely asked to present in a comparable format.
What to do instead
Evaluate on a defined total cost of ownership across the system's service life plus non-price criteria such as past performance, support capability, and compliance with the specification; require all bidders to submit lifecycle cost data in a common format so the comparison is apples to apples.