Public Records Security: What To Never Release

I got a call last year from a fire chief who had just fulfilled a public records request for CAD system logs. A journalist had asked for them. The chief handed over a spreadsheet dump straight from the system. It included the software version and the database server hostname and a few internal IP addresses.

No one had reviewed the logs before releasing them. No one had asked what the journalist actually wanted. The chief was just trying to be transparent. He was also giving an attacker a clean target profile.

This is the reality for public safety agencies under public records law. The tension between transparency and operational security is real, and most agencies are not equipped to handle it. The request that looks like a routine FOIA ask from a reporter or a graduate student can be the most effective passive reconnaissance an adversary will ever run against you.

They will never touch your network or trip your IDS. They will ask your records officer, and your records officer will hand them the information.

Public Safety Records Request Security Exemptions You Need To Know

The good news is that most states already have exemptions written for this exact problem. The bad news is that most records officers do not know they exist.

The three exemptions you need to reference: the public safety exemption, the security infrastructure exemption, and the trade secret exemption.

The public safety exemption covers records that would endanger the life or physical safety of any person or interfere with the security of a public building or facility. It applies to dispatch center layouts and server room locations, plus any record that reveals where personnel are vulnerable.

The security infrastructure exemption covers information about the security and vulnerability of critical infrastructure. This includes firewall configurations and specific software versions and security protocols. If releasing the record tells someone exactly which CVE to weaponize, this is your exemption.

The trade secret exemption applies to vendor information in contracts, and it is worth knowing how it works. CAD vendors and ePCR vendors and radio system vendors usually mark their proprietary information as trade secrets. You can use that designation to redact technical details from a contract without violating transparency obligations.

The key is not to deny the request outright. The key is to redact and cite. A clean redaction log that shows exactly which exemption you applied to each piece of removed information proves good faith while protecting the agency.

How To Redact CAD Logs for Public Records

CAD logs are the most common high-risk request I see. The requestor asks for audit logs or system metadata, which sounds administrative. But those logs contain a lot of information that a non-technical reviewer will not recognize as sensitive.

Here is what you need to find and redact:

• Software version numbers and build numbers. These tell an attacker exactly which known vulnerabilities to target.
• Server hostnames, especially if your naming convention reveals function. A server called CAD-DB-01 is telling someone exactly what they found.
• Internal IP addresses and network ranges. These are reconnaissance gold.
• Patch and reboot timestamps. Knowing your maintenance schedule tells an attacker when your guard is down.
• User account names. These feed password spraying and social engineering attacks.

The mistake I see most often is the records officer handing over a raw system export without running it past someone technical. A fire chief or an EMS director cannot be expected to know that the server name in the third column is a problem. That is why the review process needs a technical reviewer.

I covered related risks in Pre-Plan Security: The PHI-Adjacent Data Most Fire Departments Leave Unlocked. The same principle applies here. The data your systems generate as a side effect of their operation reveals more than you think it does.

Preventing Passive Reconnaissance via Public Records Requests

This is the piece that most agencies miss. An adversary does not need to breach your network to map it. They can use the public records process as their proxy.

Consider a motivated adversary making three requests over six months. They request IT service contracts first, giving them vendor names and hardware models and support tiers. Then they request CAD system logs, giving them software versions and network data. Then they request building pre-plans, giving them the physical layout of the dispatch center.

None of these requests look suspicious individually, and each one is a valid public records ask. But combined, they create a complete target profile. The adversary knows what software version you run and what your network looks like, who supports you, where your server room sits — and what your floor plan reveals.

This is the mosaic effect. Individual pieces look harmless but the composite is actionable.

You cannot stop an adversary from making multiple requests. You can make sure each request returns clean, redacted information that does not contribute to the mosaic.

FOIA Exemptions for Cybersecurity Infrastructure

If you are an agency that has done a cybersecurity risk assessment or a HIPAA security risk analysis, you have already documented your vulnerabilities. Those documents are among the most sensitive records you hold, and they are typically exempt from disclosure under state public safety and security infrastructure exceptions.

The same applies to:

• Incident response plans
• Disaster recovery procedures
• Network topology diagrams
• Security control documentation
• Vulnerability scan results

I wrote about the incident response side of this in Building an Incident Response Plan That Survives Contact With a Real EMS Cyber Incident. If your IR plan is public record, an attacker can read your playbook before they run their play. They will know who you call and what you restore first and where your backups live.

That is not a hypothetical concern. It is a direct operational vulnerability.

A Defensible Public Records Review Process

You need a process that can survive a legal challenge and also protect the agency. The process I recommend has four steps.

Step 1: Request intake and documentation. Capture what the requestor is actually asking for. Some requests are broad in a way that tells you the requestor does not know what they want. Do not assume bad faith, but document the scope clearly. If the requestor says "all CAD system logs" ask what they are trying to find. Specific scope leads to faster processing and fewer disputes.

Step 2: Technical review. The records officer should not make security decisions alone. A technical reviewer with cybersecurity experience needs to examine every record in the response set. They need to identify the pieces that a non-technical person would miss. Server names. Version strings. IP addresses. Timestamps that reveal maintenance patterns. This step is where the real protection happens.

Step 3: Redaction with statutory justification. For every piece of information you remove, cite the specific exemption. "Redacted under [state code section] — security of critical infrastructure." The redaction log is your evidence of good faith. Without it, a denial looks like obstruction.

Step 4: Aggregate risk assessment. Before you release the response, check whether the agency has fulfilled other requests recently that might combine with this one. This is the mosaic check. One request for a contract plus one request for a CAD log is not alarming. A third request for a floor plan should trigger a review of whether the requester is building a target profile.

Frequently Asked Questions

Can I legally refuse to provide a copy of our CAD system logs?

You generally cannot refuse the entire request. State public records acts require disclosure of public records. You can redact specific technical metadata like server names and IP addresses and software versions under security exemptions. The process is redact and release, not deny and withhold.

Are building pre-plans for emergency services considered public records?

The fact that a pre-plan exists is a public record, but the contents are a different matter. The detailed architectural layouts and electrical schematics and security system information inside that pre-plan are typically exempt. Most states have a specific exemption for records that would endanger the safety of a public building or the people inside it.

What is the mosaic effect in the context of public records requests?

The mosaic effect is when an adversary gathers several pieces of individually non-sensitive information from different public records and combines them into a complete vulnerability assessment. An individual contract or a CAD request or even a floor plan does not look dangerous alone. Together they tell an attacker everything they need.

Who needs to review a public records request before it is fulfilled?

At minimum, the records officer and a technical reviewer with cybersecurity knowledge. The records officer handles the legal and procedural side. The technical reviewer identifies the information in the records that would be valuable to an attacker. Neither role alone is sufficient.

What happens if I ignore a public records request?

Ignoring a public records request is not an option, and the penalties for non-compliance are real. Public records acts carry penalties for non-compliance, and ignoring a request will not make it go away. If you are unsure how to handle a request, respond within the statutory timeframe with a good-faith estimate of the time needed to process it. Work with your legal counsel and a security professional to apply appropriate redactions.

---

The fire chief I mentioned at the start of this article now has a review process. Every public records request goes through a technical review before anything gets released. He has not had a dispute since implementing it. The requestors get the information they are entitled to. The agency keeps the information that would put it at risk.

That is the balance you need — not opacity and not full disclosure but a defensible middle that respects both the law and the safety of the people who depend on your systems.

-- Steven