A new municipal records system is entering architectural design. What must occur regarding security before that design hardens?
Select an answer to reveal the explanation.
Short Explanation
You cannot draw a safe blueprint until people say what "safe" means for them. Gather stakeholder needs, write security requirements, then design. Design-first guesswork misses retention, privacy, and access rules.
Full Explanation
Before architectural design hardens for a new municipal records system, stakeholder security needs must be captured and translated into security requirements that drive the design. Records systems carry retention, privacy, access, and integrity obligations from clerks, legal, privacy officers, and public-records law. Those needs become enforceable requirements—classification, access control, encryption, audit logging, retention—that constrain architecture. Skipping this step embeds gaps that later patches cannot cheaply fix.
Coding first and reverse-engineering requirements from whatever shipped guarantees misalignment with law and policy. Asking only the hardware vendor which laws apply outsources governance and misses local records rules. Skipping stakeholder input because architects “already know” every retention rule invites silent omissions.
Exam caveat: CISSP lifecycle order is needs → security requirements → design; reversing that order is a common exam distractor.
Operational check: run structured workshops with records, legal, privacy, and ops; produce a requirements baseline with traceability IDs; require architecture diagrams to cite those IDs; freeze design only after requirements approval; re-validate when statutes or retention schedules change.