The records compliance actually asks you to keep
Most of what compliance requires is not a technical capability. It is a record — something written down at the time, retrievable later, showing that a thing happened.
That reframing is useful because it changes what you build. Systems designed to be compliant are mostly systems designed to leave a trace, and the ones that struggle are the ones where the trace was an afterthought.
Establishing which records exist and which are missing is a standard part of an it audit services engagement, and the gap is rarely where teams expect.
The six categories
Access records. Who has access to what, who approved it, when it was last reviewed, and when it was revoked. The revocation half is the one that is missing, because removing access is done and rarely recorded.
Change records. What changed in production, who authored it, who reviewed it, when it deployed. Version control and a deployment pipeline produce this as a by-product, which is why the question is really about whether a path exists that bypasses them.
Incident records. What happened, when it was detected, what was done, what changed afterwards. Also, importantly, the ones that turned out to be nothing — a log containing only real incidents suggests triage is not being recorded.
Decision records. Why a control is designed the way it is, why a risk was accepted, who accepted it. This is the category most often absent entirely, and it is the one that makes every other record interpretable.
Data records. What personal data is held, where, on what basis, for how long, and how it is deleted. This is the inventory question wearing a legal label.
Training and awareness records. Who was told what, and when. Unglamorous, frequently requested, and trivially produced if anyone thought to keep it.
The two you cannot produce afterwards
Four of those six can be reconstructed under pressure, badly. Two cannot.
Anything with a period requirement. A control operated quarterly needs four records across a year. If the first two were not created, no amount of work in month eleven produces them. This is the single most common reason a first assessment slips.
Anything that is a claim about the past. An audit trail asserts what the state was before a change. If it was not captured then, the information does not exist. Retrofitting produces a record that says what someone believes happened, which is a different artifact and an assessor will treat it as one.
Everything else — policies, inventories, diagrams — can be written the week before, and often is.
Making the record a by-product
The reliable pattern is that producing the record and performing the action are the same operation, so the record cannot be skipped without the action being skipped.
Access granted through a request that is itself the approval record. Changes deployed only through a pipeline that logs them. A quarterly review that generates a dated artifact rather than a conversation. Where the record is a separate step performed afterwards, it will be performed inconsistently, and inconsistently is worse than never — a control operated in three of four quarters is a documented failure.
Retention, which cuts both ways
Records have a required minimum and, for anything containing personal data, a maximum. Keeping everything forever is not the safe option it appears to be; it enlarges the surface of any breach and can conflict with deletion obligations.
The practical shape is a stated retention period per category, applied automatically. Manual deletion is not applied.
Where the records should live
Scattering them across wikis, inboxes and personal drives is the common state and it fails at the moment of need, when someone has a deadline and a request.
Two properties matter more than the choice of tool. The record should be timestamped by something other than the person who wrote it, and it should be retrievable by someone who was not involved. A dated document in a shared system satisfies both; a message thread satisfies neither.
Where the records are generated by the system — access requests, deployment logs, review artifacts — leaving them where they were produced is usually better than copying them somewhere tidy, because the copy loses provenance and gains a maintenance burden.
What this does not settle
It does not tell you which framework applies to you or what your specific regulator expects, and I would not guess at that. The categories above are what the common technical standards request; the interpretation for your jurisdiction and sector is a question for a lawyer or a qualified assessor.
It also does not make you compliant. Records evidence controls. If the control is weak, a perfect record documents a weak control faithfully.
Related reading: what a compliance audit proves covers the exercise these records feed, protecting sensitive information covers the controls behind the data records, and information security covers the wider question of evidencing security rather than asserting it.