Skip to main content
SYSTEM ONLINE · aws us-west-1 · build 26.04.2
POs & NET 30 accepted · 559-251-7767 · Fresno, CA
SentraCheck // document compliance
Login Request a Demo
Public Records • August 2026

Answering CPRA Requests Faster: What a Document Index Buys You

The statutory clock does not care that your records are spread across four systems and a shared drive. Most of a records response is spent looking, not deciding.

The California Public Records Act obliges an agency to determine, within ten days of receiving a request, whether it holds disclosable records responsive to that request, and to tell the requester. That window can be extended in unusual circumstances, and records themselves are to be made promptly available. The Act was recodified in 2023, so older references to Government Code section 6250 and following now point to sections 7920.000 and following.

Not legal advice. CPRA timelines, exemptions, and fee rules turn on specifics. Your agency counsel and your adopted records policy govern how you respond to any particular request.

What follows is not about the law. It is about why responses take as long as they do, and what fixes the slow part.

Where the time actually goes

Ask a records officer to break down a typical response and the shape is consistent:

PhaseWhat happensShare of effort
InterpretationWorking out what the requester actually wantsSmall
SearchFinding candidate records across systems and departmentsLarge
ReviewReading for exemptions and privileged contentLarge
RedactionRemoving exempt material and verifying it is goneModerate
ProductionAssembling, logging, and deliveringSmall

Search and review dominate. Search is the phase that infrastructure can fix; review is the phase that requires judgment and cannot be automated away. So the practical question is how much of the clock you can buy back from search.

Why search is slow

Not because anyone is being slow. Because the records live in places that do not share an index:

  • The website CMS, with its own search that only covers page text
  • The agenda platform, searchable only within itself
  • The permitting or utility system, searchable by parcel or account but not by content
  • Shared drives, where search depends on file names
  • Email, which is its own project entirely
  • Scanned archives with no text layer, which are not searchable at all

That last one is the quiet killer. If a quarter of your scanned records are image-only PDFs, they are invisible to every search tool you own. A staff member has to know they exist and open them one at a time.

What an index changes

A document index is a single table of everything you hold that is subject to a request, with enough metadata to narrow a search before anyone opens a file. At minimum: title, file name, owning department, date, record series, page count, content hash, and whether a text layer exists.

With that in place, several things stop being manual:

  • Scoping the search. "Every document from Public Works dated 2019–2021 relating to this project" becomes a filter instead of six emails.
  • Finding duplicates immediately. Hash matching means the same attachment appearing in four systems is reviewed and redacted once, not four times.
  • Routing to the right custodian. The owning-department field turns "who would know about this?" into a lookup.
  • Knowing what you cannot search. A flag for image-only files tells you exactly which part of the corpus still needs human eyes.
  • Defensible completeness. When a requester challenges the adequacy of a search, an index gives you a documented description of what was searched and how.

Redaction, and the mistake that follows it

Once responsive records are found, exempt material has to come out. The failure mode here is well known and still common: drawing a black rectangle over text in a PDF annotation tool hides it visually while leaving the characters in the file. Anyone can select the text underneath, or extract it with a command-line tool, or read it in the browser's own text layer.

True redaction removes the underlying content. Always verify afterward by extracting the text of the produced file and searching it for the terms you removed. See finding PII before you publish for the full verification workflow.

Reduce the requests themselves

The cheapest response is the one you never have to make. Agencies that publish frequently requested categories proactively see repeat requests fall, because requesters find what they need without asking.

To find your candidates, analyze your request log for the last two years and count requests by record series. The top handful is almost always predictable — permits and plans for a given address, agendas and minutes, contracts and bid results, budgets and financial reports, and the same recurring policy documents.

Two cautions before you publish anything in bulk:

  1. Scan for personal information first. Historic files carry material that was fine in a filing cabinet and is not fine on the open internet.
  2. Published documents have to be accessible. Moving a record series onto the website brings it inside your ADA Title II obligations. Plan the remediation as part of the publication decision, not as a surprise afterward.

Metrics worth tracking

  • Median days from request to determination, and to production
  • Staff hours per request, split between search and review
  • Share of requests satisfied entirely by already-published material
  • Requests by record series, reviewed quarterly to update your proactive publication list
  • Share of the corpus that is text-searchable — the single best predictor of how fast search will go

The index pays for itself outside of CPRA too. The same inventory drives your retention program, sizes your accessibility remediation, and identifies duplicate documents. It is one piece of work that four different obligations depend on.

Make your documents findable

A corpus audit gives you a searchable inventory of every public document with dates, departments, page counts, and duplicates — the index a records officer wishes existed.

Request a Demo More Articles