The WordPress records-retention problem nobody on your team has mentioned yet
Records retention is the WordPress conversation that surfaces during an FOI request or a Library and Archives audit, never before. By that point, the answers your CMS gives are the wrong ones.
If your site is a marketing brochure with no FOI exposure or institutional record-keeping obligation, close this tab. This is for organizations carrying regulatory or institutional retention obligations on content WordPress publishes.
What WordPress remembers, and what it quietly forgets
Out of the box, WordPress keeps posts indefinitely, keeps every revision indefinitely, and loses trashed content for good once the trash is emptied. None of those three defaults matches an institutional retention schedule, and each one is its own audit finding waiting to happen. The good news I give clients first is that WordPress has real redundancy underneath it, and a well-structured backup will put your data back with very little effort on the day something goes the way you did not want.
WordPress was built to publish, and it is genuinely good at that job. Publishing asks what the public should see right now. A retention schedule asks a longer question: what used to be here, who changed it, when, and who authorized it going away. Revisions look like they answer that, and they fooled me early on, right up until somebody edits content with a bulk tool outside the editor, or a performance plugin trims the revision table because it had grown big enough to slow the admin down.
The trash is worse, because emptying it is a genuine delete with nothing written down afterward, no time stamp and no name attached to it. Your site is now correct and your evidence is gone, in the same click. Closing that gap takes a written policy, automation that enforces it, somewhere durable to record what the automation did, and a person whose job includes reading that record. None of the four stay working unattended, which is why this belongs with ongoing WordPress maintenance rather than in a launch budget.
How far an FOI request actually reaches
An FOI request reaches well past the published site. It pulls in drafts sitting in the database, revisions, content parked in a trash nobody emptied, staging copies, form submissions sitting in a plugin table that nobody on the web team thinks of as content, and the backups. Backups are the one that surprises people. If you hold ninety nightly snapshots, you are holding ninety copies of the material you carefully disposed of last month, and the redundancy that saves you on a bad day is discoverable on a worse one.
Here is the structural problem in a line: the records officer signs the disclosure, but the CMS is the evidence. What they sign about is whatever the database can be made to say, and if it cannot say when a page changed or who changed it, the honest sentence in your response letter is that you do not know. That sentence is expensive in a way that has nothing to do with hosting. The same shape shows up on the way out the door, which is what I get into in the records-management cost of migrating off a hosted government CMS. The obligation follows the content, not the platform it happened to be living on.
In Canada this sits above internal policy preference. Federal institutions are bound by the Library and Archives of Canada Act, where section 12 requires the Librarian and Archivist’s written consent before any government record is disposed of, and by the Treasury Board Directive on Service and Digital (which replaced the older Directive on Recordkeeping in 2020); provincial bodies work under their own public records legislation. I am not your records officer and none of this is legal advice. What I need from that conversation is which retention rules attach to which content, because that decides the job the site has to do. It is one of the obligations I raise early, alongside the other questions a government discovery call should cover.
What a defensible setup looks like, and what it costs
Think about the temperature log taped to the wall of a restaurant kitchen. The inspector cares far less about the fridge than about that sheet beside it, with a temperature and a set of initials on it, twice a day, going back months, because any fridge can be cold on the morning an inspector walks in. The sheet is the only proof it was cold on the days nobody was watching. Deleting content on schedule is the easy half of retention. Showing that you deleted it on schedule, under which rule, and on whose authority, is the half that gets audited.
So the setup I trust starts with a retention schedule mapped onto your post types and taxonomies, so the rules live where the content lives. Then automated disposition that writes to an audit log every time it runs, including the runs where it finds nothing to do, since a log with gaps in it invites questions about the gaps. Then backup retention aligned to legal hold instead of kept forever, because forever is a liability wearing the costume of caution. And a review on the calendar with a real name on the sign-off, because an unowned process is one staff change away from stopping quietly.
Rough numbers, because people ask and I would rather say them out loud than make you book a call to hear them. Implementation of retention automation and an audit log runs $10,000 to $25,000, depending on how many content types carry obligations and how much existing history needs backfilling. Ongoing review and disposition operations run $3,000 to $8,000 a year. The cost of finding out you needed all of it during an FOI response is the one I cannot quote, and it is rarely the invoice that hurts, it is the calendar.
If you are carrying an obligation like this and you do not know what your site would say under audit, there is a cheap first test. Pick one page you know changed last year, and ask your team for the date it changed and the name of the person who changed it. If that takes longer than a coffee, you already have your finding, and a conversation about it now costs a good deal less than the same conversation under a statutory clock.