IP addresses and your forms

The GDPR defines personal data in Article 4(1) as information about an identified or identifiable person, and names “an online identifier” as one way a person can be identified. Recital 30 gives IP addresses as an example of such an identifier.

The Court of Justice settled the harder case in Breyer v Bundesrepublik Deutschland (C-582/14), decided on 19 October 2016. A website operator usually cannot tell who sits behind a dynamic IP address. The Court held that the address is still personal data for the operator when it has legal means to identify the person with additional data held by the internet provider, for example through the authorities after an attack. The case was decided under the old Directive 95/46, but the definition it interpreted carried over into the GDPR.

The practical reading for a form owner: treat the IP addresses your forms collect as personal data, and design around that.

• Web server and proxy logs, for the page that shows the form.
• The form backend, which often keeps the address with the submission for rate limiting and abuse checks.
• A CDN or firewall in front of either of them.
• A CAPTCHA or bot check, which the visitor's browser talks to directly.
• Analytics on the page, if any.

Each one is a separate copy with its own retention and, often, its own location. When you write your record of processing, list them all, not only the form backend.

A common shortcut is to store a SHA-256 hash of the address. It looks unreadable, but the IPv4 space has only about 4.3 billion addresses. Hashing every one of them takes little time on ordinary hardware, after which each stored hash maps straight back to its address.

A keyed hash (an HMAC with a secret key) closes that gap for anyone who does not hold the key. In GDPR terms that is pseudonymisation under Article 4(5): the data can no longer be linked to a person without additional information that is kept separately. Recital 26 is explicit that pseudonymised data is still personal data. So a keyed hash is a good safeguard under Articles 25 and 32, not an exit from the regulation.

Spam and abuse protection is the usual reason a form keeps an IP address. Recital 49 states that processing strictly necessary for network and information security is a legitimate interest, which points to Article 6(1)(f). That basis comes with a balancing test, and the balance favours keeping as little as possible for as short as possible.

A rate limit needs the address for minutes, not months. If nothing else depends on it, there is little reason to keep the IP linked to a submission for as long as the message itself. Whatever you choose, say so in your privacy notice.

• Keyed hash on receipt. The submitter's address is hashed with HMAC-SHA-256 and a secret server-side salt before anything is stored. The raw address is not written to disk.
• Used for rate limiting. The hash is what the per-IP, per-form rate limit counts against. By default that is 50 submissions a minute per address, and you can set a lower or higher limit per form.
• 24-hour removal. In the Privacy center a workspace owner or admin can set a form to drop the hash 24 hours after each submission. A sweep runs every 15 minutes. Without that setting, the hash is kept as long as the submission.
• Anonymous hosted forms. A hosted form set to anonymous stores no IP hash with its submissions at all.
• Server logs. Web server access logs keep only a truncated address, as described in the privacy policy.

One exception sits outside Formward's servers. If you switch on Cloudflare Turnstile for a form, the visitor's browser talks to Cloudflare, a US company, which sees challenge data such as the IP address and browser signals, but no form answers. It is off unless you enable it, and it is listed in the sub-processor register. The _gotcha honeypot and the rate limit work without it.