Data security protocols, access controls, backup procedures, and breach response. Covers FERPA, health information protection, and public records sensitivity.
2
hours
0.2
CEUs
Administrative, Legal & Management
1.7.4
Data security protocols, access controls, backup procedures, and breach response. Covers FERPA, health information protection, and public records sensitivity.
Format
On-Demand Online
Delivery
Self-Paced
Access
24/7 After Enrollment
Certification
Certificate of Completion
Have questions about this course or our platform?
Contact our support teamImplement cybersecurity measures for permit and inspection data
Building departments sometimes assume they are too small or too boring to attack, and that assumption is the first vulnerability. Consider what the department actually holds: permit applications carrying names, home addresses, phone numbers, and contractor license information; payment records from counter and online transactions; personnel records; and construction plans — including plans for schools, banks, utility facilities, and courthouses, whose security details, alarm layouts, and access points are exactly what a burglar or worse would want. Local governments as a class have proven attractive ransomware targets: they run essential services that cannot stay down, often on older systems with thin IT staffing, and the pressure to restore service is intense. Most attacks are opportunistic, scanning for any organization with an unpatched system or a staff member who will click a link — a department connected to the internet is in the target pool by default.
Protection starts with a data inventory mindset, because no one can protect what they have not identified. List what the department holds, where each kind of data lives, and who can see it. Permit and inspection data may live in the permitting system, but copies accumulate elsewhere — scanned applications on shared drives, plan sets on field tablets, payment details in email threads, decades of paper in the records room, and hosted data on a vendor's servers. Building Department Administration notes that security must protect both information and hardware from theft and tampering, and that exposure grows particularly where there is web-based interaction with the public — which now describes nearly every department. It also makes a governance point: rather than building separate security just for the permitting system, it is frequently better to adopt the jurisdiction's existing security protocols so practice is consistent across the organization. The building official's job is not to design firewalls; it is to know what the department holds, insist that jurisdiction IT protections cover it, and enforce the daily habits no firewall can replace.
On the system side, a non-IT manager needs command of only a few fundamentals. First, patching: most successful attacks exploit known flaws for which fixes already existed, so updates are applied promptly, not deferred because "the system is working." Second, least privilege: each account gets only the access its holder's duties require — developed further in Module 2. Third, backups: Building Department Administration is emphatic that redundancy is vital, and that the permitting system and its records must be protected and routinely backed up on a separate server, with supporting measures such as an uninterruptible power supply; some vendors offer fail-over servers updated perhaps every hour or two — a delay many jurisdictions can accept for considerable savings. Critically, at least one backup copy should be kept disconnected from the network — ransomware that encrypts the live system will also encrypt any backup it can reach — and backups must be periodically test-restored, because a backup never proven readable is a hope, not a safeguard. These are not merely security measures: permits and certificates are permanent legal records, so protecting the electronic system of record is a records-retention obligation and a core element of continuity-of-operations planning. Recognized public frameworks from bodies such as NIST and the Center for Internet Security cover the same ground in depth and give small governments a credible baseline to ask their IT support to work toward.
A new building official asks a deceptively simple question: "What data do we have, where is it, and who can get at it?" The inventory is sobering. A shared folder open to every employee contains years of scanned contractor registration forms, some bearing Social Security numbers from an old form design. Two field tablets hold complete plan sets for the county courthouse renovation; neither requires a passcode. A spiral notebook at the counter holds card numbers written down during phone payments "to enter later." The nightly backup goes to a second drive — mounted permanently on the same server. None of this reflects bad intent; each item accumulated from a reasonable shortcut. The official works the list: old forms are purged of Social Security numbers under the records procedure; tablets get passcodes, encryption, and remote-wipe through jurisdiction IT; the notebook is replaced with immediate entry into the payment system; and IT adds an offline backup copy with a quarterly test restore. Nothing here required a security specialist to find — only someone who asked the inventory question.
The foundational mistake is "we're too small to be a target" — opportunistic attacks find any exposed system, so baseline protection is simply a cost of holding public data. A second mistake is treating security as purely an IT problem; hygiene failures at the counter and in the field defeat technical controls, so security is managed like safety — everyone's responsibility, led from the top. Third is collecting and keeping data the department does not need; every unnecessary Social Security or card number on file is pure liability, so forms and processes collect the minimum. Fourth is the untested, always-connected backup — corrected by a separate offline copy periodically restored and read. Finally, departments err by building one-off security for the permitting system alone instead of joining the jurisdiction's protocols, losing both consistency and jurisdiction IT support.
Manage access controls and user authentication
Access control answers one question continuously: who can see or change what, and why? The governing principle is least privilege — each person holds only the access their duties require. Building Department Administration reaches this principle from the records side: if every clerk can amend computer records, such as changing an address or a fee amount, the administrative authority can never be certain a record is accurate, so amendment authority belongs to selected staff only, with supervisory review. The same logic extends across the system: permit technicians need entry and lookup rights, not fee-table administration; inspectors need to record results, not delete permits. Three disciplines make least privilege real. Every user gets an individual account — a record change traceable only to a shared "counter1" login is traceable to no one. Access is reviewed periodically, because privileges accumulate as people change roles but are rarely taken away. And when an employee separates, accounts are disabled the same day as part of the standard checkout process, not weeks later when someone remembers.
Authentication is the lock on those accounts, and staff practice is where it holds or fails. Long passphrases beat short complex passwords; every system gets a unique credential, since a password stolen from any breached website will be tried against the department's systems; and a jurisdiction-approved password manager makes unique credentials practical. Multi-factor authentication — the code or prompt on a second device — is the single most effective upgrade available because it defeats most stolen-password attacks outright; it belongs on email, remote access, and permitting system accounts, starting with administrators. Around authentication sits everyday hygiene: screens lock when staff step away from the counter, where the public stands feet from workstations displaying other applicants' information; field tablets avoid open public Wi-Fi in favor of cellular or jurisdiction-provided connections; and found or unsolicited USB drives never get plugged in. Above all, staff learn to recognize phishing — the fraudulent email impersonating a trusted party. Two patterns deserve particular drilling: the fake invoice or account-verification message that harvests credentials through a lookalike login page, and the vendor change-of-bank-account request aimed at whoever pays invoices. The defense for both is procedural: never act on emailed requests involving credentials or payment changes without verifying by telephone at a number already on file — never a number supplied in the email itself.
Two further access questions belong to the building official rather than to IT. The first is hosted-system diligence. When permit data lives on a vendor's servers, Building Department Administration advises jurisdictions to verify that they own the hosted data and to establish procedures for obtaining copies of it — and the contract should also state where the data resides, obligate prompt notification of any breach affecting the jurisdiction's data, and guarantee export of complete records in usable formats at termination. These terms are evaluated at procurement, because they are nearly impossible to add later. The second is the public-records tension. Most of what the department holds is a public record, and transparency obligations are real — but disclosure laws also recognize protected categories. Personal identifiers are redacted before release, and plans of critical or sensitive facilities — security system layouts, camera placements, vault details, utility infrastructure — are released only after review, under whatever protection state law and legal counsel support. Neither blanket secrecy nor blanket disclosure is defensible; the department needs a documented, counsel-reviewed procedure for the sensitive subset.
A records request arrives for the complete approved plan set of the city's water treatment facility, submitted by an unnamed requester through a web form. The counter technician recognizes a request that does not get filled on the spot: the set includes security fencing details, control system locations, and chemical storage layouts. Under the department's counsel-reviewed procedure, the request is logged and routed for legal review; the response releases the non-exempt portions and withholds the protected security details, with the statutory basis documented. The same month, an access review finds that eleven of fourteen staff hold full administrative rights "because that's how accounts were set up," and that a plans examiner who resigned in the spring still has an active remote login. Roles are rebuilt around actual duties, the orphaned account is disabled, and deactivation is added to the personnel checkout form. The department did not need new technology for any of this — it needed the access question asked deliberately.
The classic failure is the shared login, which makes every record change anonymous; the correction is individual accounts with rights matched to duties. Its twin is the orphaned account that outlives the employee — corrected by tying deactivation to the separation checklist. Third is universal administrator rights granted for convenience; the correction is periodic access review against actual duties, echoing the administration text's warning about unrestricted amendment authority. Fourth is skipping multi-factor authentication because it adds a step — the step is precisely the point. Fifth is signing a hosted-system contract silent on data ownership, breach notification, and export rights, terms that must be negotiated at procurement. Finally, departments err in both directions on public records — releasing sensitive facility plans unreviewed, or reflexively refusing legitimate requests; the correction is a documented procedure, built with legal counsel, honoring both obligations.
Respond effectively to data breaches and security incidents
Incident response is decided before the incident, by whether a plan exists and whether staff will use it. The plan can be short, but it must answer the first-hour questions: who is called, in what order, and what frontline staff do and do not do. For a staff member who suspects a compromised machine — strange encryption messages, files renamed en masse, a link clicked and immediately regretted — the "do" list begins with disconnecting the machine from the network so the problem cannot spread, and reporting immediately to the designated contact. The "do not" list matters just as much: do not delete files or reinstall software, because the system is now evidence of what happened and what data was touched; do not investigate alone; do not stay quiet out of embarrassment. The culture must make the fast reporter a hero and never punish the honest click — an employee who hides a mistake for three days converts a contained incident into a department-wide one. Certain decisions sit above frontline and even department level: whether a ransom would ever be paid involves executive leadership, legal counsel, the jurisdiction's insurer, and law enforcement — no inspector, technician, or building official freelances that answer. Notification runs on the same track: breach notification duties vary by state and by what data was exposed, so counsel determines who must be told, when, and how; the department preserves evidence and supplies facts.
Recovery is where Module 1's backup discipline pays off or fails. An offline, test-restored backup converts ransomware from a catastrophe into an outage: systems are rebuilt, records restored, and the demand letter becomes irrelevant. The redundancy measures described in Building Department Administration — routine backup to a separate server, uninterruptible power, fail-over arrangements — exist precisely so the department's permanent records survive the loss of any single system. Continuity-of-operations planning carries the department through the gap: permits can be issued and inspections recorded on paper forms for days or weeks if fallback procedures were prepared, with the paper record entered into the restored system afterward. Public communication belongs in the plan too — a short, honest statement that systems are affected, core services continue by alternate means, and updates will follow beats both silence and speculation. When the incident closes, the response is not finished until the after-action review asks how the attacker got in, what worked, what stalled, and which fixes carry owners and due dates. Recognized incident-response guidance from sources such as NIST follows this same arc — prepare, detect, contain, recover, learn — and gives jurisdictions a template to adapt.
On a Tuesday morning, a counter technician receives an email that appears to come from the department's plan-review software vendor: the logo is right, the account manager's name is right, and the message says the vendor has "updated its payment portal" — log in through the attached link to keep review services uninterrupted, and note the vendor's new bank account for the current invoice. It is polished, plausible, and urgent. The technician does what the department drills: nothing gets clicked. She calls the vendor at the number on file from the original contract; the account manager confirms there is no new portal, no new bank account, and no such email. She forwards the message to jurisdiction IT, which confirms the sending domain is a lookalike, blocks it, and sends a department-wide alert with a screenshot. Total elapsed time: under an hour. Had credentials been entered, the department would have been in incident response — password resets, access audits, counsel consultation about exposure. Instead, one verify-by-phone habit closed the incident before it opened. Attackers study who departments trust; the defense is a habit, not a technology.
The most damaging mistake is silence — the employee who conceals a click, or the department that conceals an incident from jurisdiction leadership; the correction is a no-blame culture that makes reporting the celebrated first step. Second is the wrong first move: wiping or reinstalling a compromised machine destroys the evidence needed to determine what was exposed — disconnect and report, then leave forensics to those equipped for it. Third is freelancing the big decisions; ransom and notification questions belong to leadership, counsel, insurers, and law enforcement, and the plan says so in writing. Fourth is discovering at recovery time that backups were connected, corrupted, or never tested — a Module 1 failure that only reveals itself here. Fifth is having no paper fallback, so a system outage becomes a service shutdown. Last is skipping the after-action review, which forfeits the only good thing an incident offers: the lesson.
This course provides professional development in cybersecurity and data protection for building departments. Departments hold personal information from applications, payment records, personnel data, and plans of sensitive facilities, and local governments are proven targets for ransomware and fraud — so protection is an administrative duty, not an IT courtesy. The course builds three competencies: implementing baseline safeguards grounded in a data inventory and the backup and redundancy obligations described in Building Department Administration; managing access through least privilege, multi-factor authentication, disciplined vendor contracts, and a counsel-reviewed balance between public-records transparency and protection of sensitive information; and responding to incidents through disconnect-and-report first steps, decisions escalated to leadership and counsel, evidence preservation, tested backups, and continuity fallbacks. Throughout, the emphasis is on habits and procedures a non-IT audience can own — because most incidents begin, and most are prevented, at the counter and in the field.