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

If your inbox looks like ours this week, it's wall-to-wall "We've updated our privacy policy" emails — the sound of an entire industry hitting the same deadline at once. 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. Which, if you run a website with European visitors, almost certainly means you.

One thing up front: we are not lawyers, and this is not legal advice. GDPR is a sprawling regulation with genuine legal nuance, and if your business handles significant personal data, you should talk to someone qualified. What we can offer is the practical 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 wearing a legal hat.

IP addresses are personal data — which means your logs are in scope

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

Follow that thread and it leads somewhere uncomfortable: your server logs are a personal-data processing system. So is your analytics tool. Practical consequences:

• Know where IPs accumulate. Web server access logs, application logs, analytics, your CDN's logs, security tooling. You can't make policy decisions about data you haven't located.
• Ask whether you need all of it. Data minimization is a core GDPR principle — the cheapest data to protect is data you don't collect. Many analytics tools now offer IP anonymization (truncating the last octet); turning it on costs you almost nothing.
• Nginx and Apache make anonymization easy if you want it at the source:

# 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 question

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 clear that bar.

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/tracking cookies are where consent obligations concentrate.
• Does your banner actually do anything? A banner that announces cookies while setting them regardless is theater. If you determine you need consent for a category of cookies, the honest implementation doesn't set them until the visitor agrees.
• Re-permission your mailing lists if needed. That flood of "please confirm you still want to hear from us" emails exists because consent obtained loosely years ago may not meet the new standard. If your list was built on clear opt-in, you're likely in decent shape; if it was built on prize draws and pre-ticked boxes, this week's panic is yours too.

Inventory your processors — 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, payment processing, hosting, CRM, support desk, your monitoring vendors — is a processor. You're expected to know who they are and have data processing agreements (DPAs) in place with them.

The exercise is clarifying even apart from the law:

• List every third party in the request path or data flow. Walk 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 spent this spring publishing one — it's what half those inbox emails are about. Ours is available on request, like most.
• Note data locations. Transfers outside the EU need a legal basis (adequacy, standard contractual clauses, or frameworks like Privacy Shield for US vendors). You don't have to become an expert — you do have to be able to answer "where does this data go?"

The 72-hour breach clock — you can't report what you haven't detected

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

Read that carefully — the clock starts at awareness, but regulators expect you to be capable of becoming aware. An organization that couldn't detect a breach for six months doesn't get credit for its ignorance; it gets questions about why it had no detection in place. Which means monitoring and incident detection are now part of your compliance posture, not just your ops hygiene:

• You need to notice anomalies. Defaced pages, unexpected content changes, certificate swaps, DNS records pointing somewhere new — these are how compromises often first surface externally. Automated change detection turns "a customer emailed us" into "we got an alert."
• You need timestamps. The 72-hour narrative requires knowing when things happened. Monitoring history and alert logs are exactly the evidence trail "when did you become aware?" demands.
• You need an incident procedure. Who assesses severity? Who drafts the notification? Even a one-page runbook written this week beats improvising against a 72-hour deadline.

Log retention: "forever" is no longer a policy

GDPR expects personal data to be kept no longer than needed — and named retention periods, not indefinite accumulation. For logs, that means picking a number and enforcing it. Ninety days of raw access logs is a common, defensible operational 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 point isn't the specific number — it's that "we keep everything forever because disk is cheap" now needs to be a decision you can justify, not a default you never examined.

Compliance posture is mostly just knowing your own systems

Strip away the legal vocabulary and most of this checklist is things a well-run website should have 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 the detection half of that posture — uptime, SSL and DNS monitoring with alerting and a timestamped history of what changed and when, in one dashboard. Create a free account before Friday, and make "when did you become aware?" a question you can answer to the minute.

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