GDPR Lands in Three Days: A Practical Checklist for Website Operators

If your inbox looks like ours this week, it's full of "We've updated our privacy policy" emails, the sound of an entire industry hitting the same deadline. The EU's General Data Protection Regulation takes effect this Friday, May 25th, and applies to anyone, anywhere, who processes the personal data of people in the EU. If your website has European visitors, that almost certainly includes you.

First: we are not lawyers, and this is not legal advice. GDPR is a large regulation with real legal nuance, and if your business handles significant personal data, talk to someone qualified. What we can offer is the operator's view: the concrete things a website team should have inventoried and decided before Friday, and the parts of compliance that are really just good operations.

IP addresses are personal data, so your logs are in scope

The point that surprises most technical people is how broad GDPR's definition of personal data is. IP addresses count. So do device identifiers and tracking cookie IDs. Anything that could identify a person, directly or combined with other data, is in scope.

That means your server logs are a personal-data processing system, and so is your analytics tool. In practice:

• Know where IPs accumulate. Web server access logs, application logs, analytics, your CDN's logs, security tooling. You can't set policy for data you haven't located.
• Ask whether you need all of it. Data minimization is a core GDPR principle, and the cheapest data to protect is data you never collect. Many analytics tools offer IP anonymization (truncating the last octet), and turning it on costs you almost nothing.
• Anonymize at the source if you want to. nginx makes it straightforward:

# nginx: log a truncated IP instead of the full address
map $remote_addr $ip_anon {
    ~(?P<ip>\d+\.\d+\.\d+)\.    $ip.0;
    ~(?P<ip>[^:]+:[^:]+):       $ip::;
    default                     0.0.0.0;
}
log_format anon '$ip_anon - $remote_user [$time_local] "$request" $status';

Consent and the cookie banner

GDPR raises the bar for consent: it must be freely given, specific, informed, and as easy to withdraw as to give. Pre-ticked boxes and "by using this site you agree" boilerplate don't meet it.

For a typical website the practical questions are:

• What are you setting cookies for? Strictly necessary cookies (sessions, security, load balancing) are on solid ground. Analytics and especially advertising and tracking cookies are where consent obligations concentrate.
• Does your banner actually do anything? A banner that announces cookies while setting them regardless doesn't achieve much. If you need consent for a category of cookies, don't set them until the visitor agrees.
• Re-permission your mailing lists if needed. The flood of "please confirm you still want to hear from us" emails exists because consent collected loosely years ago may not meet the new standard. A list built on clear opt-in is probably in decent shape. One built on prize draws and pre-ticked boxes is not.

Inventory every vendor that touches your users' data

Under GDPR you're the controller of your users' data, and every third-party service that processes it on your behalf (analytics, email delivery, payments, hosting, CRM, support desk, monitoring) is a processor. You're expected to know who they are and to have data processing agreements (DPAs) with them.

The exercise is useful even apart from the law:

• List every third party in the data flow. Walk through a user's journey and note every external service their data touches. Most teams find at least one they'd forgotten.
• Collect DPAs. Nearly every serious vendor has published one this spring; it's what many of those inbox emails are about.
• Note data locations. Transfers outside the EU need a legal basis (an adequacy decision, standard contractual clauses, or Privacy Shield for US vendors). You don't need to become an expert, but you do need to be able to answer "where does this data go?"

The 72-hour breach clock

This is the part of GDPR that lands in operations. When a personal data breach is likely to put people's rights and freedoms at risk, you must notify your supervisory authority within 72 hours of becoming aware of it.

The clock starts at awareness, but regulators will expect you to be capable of becoming aware. An organization that couldn't detect a breach for six months won't get credit for not knowing; it will get asked why it had no detection. So monitoring and incident detection are now part of your compliance posture:

• Notice anomalies. Defaced pages, unexpected content changes, certificate swaps and DNS records pointing somewhere new are often how compromises first show up externally. Automated change detection turns "a customer emailed us" into "we got an alert".
• Keep timestamps. Answering "when did you become aware?" requires knowing when things happened. Monitoring history and alert logs are that evidence.
• Have an incident procedure. Who assesses severity? Who drafts the notification? A one-page runbook written this week beats improvising against a 72-hour deadline.

Log retention: "forever" isn't a policy

GDPR expects personal data to be kept no longer than necessary, with defined retention periods. For logs, that means picking a number and enforcing it. Ninety days of raw access logs is a common, defensible choice. Whatever you pick, automate the deletion:

# logrotate: keep 90 days of access logs, then they're gone
/var/log/nginx/access.log {
    daily
    rotate 90
    compress
    missingok
}

The exact number matters less than the fact that "we keep everything because disk is cheap" now has to be a decision you can justify.

Compliance is mostly knowing your own systems

Without the legal vocabulary, most of this checklist is what a well-run website should do anyway: know what data you collect, know which vendors touch it, delete what you don't need, and be able to detect and timestamp incidents. GDPR just made the deadline real.

CompleteStatus helps with detection: uptime, SSL and DNS monitoring with alerting and a timestamped history of what changed and when, in one dashboard. Create a free account and make "when did you become aware?" a question you can answer to the minute.

Again, this is not legal advice. For the hard questions, ask a lawyer who does this for a living.