This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
Personal data is a duty, not a dataset to enrich
Privacy for an admin is knowing which systems hold personal data, who may see it, and how long you keep it. The redactor removes patterns from text you are allowed to hold. It is not a way to identify someone from an anonymised file. The privacy policy generator drafts headings. Counsel decides whether the draft is true.
A name, an email, a government number, a health detail, a precise location: treat them as personal until counsel says otherwise. The database desk's PII guide is the companion when the data lives in a table. This page is the decision and the redaction habit.
A request from a person to see or delete their data is a process with an owner and a deadline you were given. You do not invent the legal answer. You find the systems.
Logs often contain more personal data than the application. A detection that needs a mailbox name is not a reason to copy the mailbox into a chat.
One export, redacted before it leaves the room
Take a lab export you created, with fake names. Run the redactor. Read the output. A fake email that survived is a pattern to add, not a reason to send the file anyway. A real export waits until this drill works.
Write where the real data lives: the application, the backup, the log, the vendor. Each location gets a retention sentence. Forever is a sentence you must justify.
The policy draft is a list of those sentences. It is marked draft until counsel says it can be published. Do not put it on the website in this window.
Access is the identity guide. People who do not need the export do not get the file, including a future you who pasted it into a ticket.
A change you can finish
The change is the inventory and the redaction habit. A new processing purpose is a counsel question, not an admin shortcut.
Rollback of a bad redaction is the original, which stayed in the restricted store and was not the file you sent.
- List systems that hold personal data you administer.
- Redact a fake export and read what remains.
- Write retention for each system.
- Keep the real file in the restricted store.
- Mark the policy generator output as a draft.
- Give access requests an owner.
- Do not try to re-identify anyone.
Mistakes that outlive the command
data privacy fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Pasting a live export into a ticket.
- Publishing a generated policy without counsel.
- Using the redactor on data you are not allowed to hold.
- Trying to undo anonymisation.
- Retention of forever by default.
- A backup that ignores the deletion you promised.
- Sharing the unredacted file because the redacted one looked incomplete.
- Legal conclusions in the inventory.
Decisions to write down before the window
One decision for data privacy: The inventory lists systems, not a dump of the data. The redactor was proven on fake data. Unredacted files stay restricted. Retention is a sentence per system. The policy is a draft until counsel publishes it. Access and deletion requests have an owner. Backups are part of the inventory. The database guide owns table-level detail. Re-identification is out of scope. And framework guides such as GDPR are readiness, not this page's legal opinion.
The hour you stop
Write the hostname or the system name, the owner, and the clock time before you change anything for data privacy. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.
Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.
prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.
One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.
A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.
Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.
Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.
Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.
If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.
When the checks pass, the next system waits until someone else can repeat the proof from the notes. data privacy is done for this window when the proof is written, not when the tool printed a file.
This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.
Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.
Privacy checks before any file leaves the team
Confirm this before you call the change done: The file you share is the redacted lab file or a counsel-approved extract. Fake data was the first redaction test. Remaining patterns were reviewed. The inventory names systems and owners. Retention is not blank. The policy file says draft. No re-identification steps are in the ticket. Backups are listed. A second person saw the redacted output. The original is still restricted. Access requests have a path. Counsel is named for notice questions. The hostname in the prompt matches the hostname in the ticket for data privacy. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for data privacy happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- How-To: Redacting PII from Logs and Documents
- Explainer: Cookie Consent Requirements Explained
- How-To: DPIA Explained
- How-To: Handling Data Subject Requests
- How-To: Data Retention Schedules
- How-To: Records of Processing (ROPA)
- How-To: Writing a Data Breach Notification
- Explainer: GDPR Fines Explained
Companion: DBA: Finding and Protecting PII in Databases.