GDPR

How Loghound fits the GDPR, written by engineers so your lawyer has something accurate to read. It is not legal advice.

• Roles. You are the controller. Loghound is software, not a service, and there is no Loghound entity that processes anything. Opensolr hosts your two indexes and is a processor; you need the usual paperwork with them.
• Lawful basis. Server-log analytics is commonly run under legitimate interest, and that is easier to argue here than for most analytics: it processes logs you already keep, sets no cookies, does no cross-site tracking, and much of its purpose is security. Do a legitimate interests assessment and write it down.
• Cookie banner. The beacon stores nothing on the device: no cookie, no local storage. On the common reading that means no consent banner is needed for it. Regulators differ, so check your own jurisdiction.
• Data minimisation. Choose the address mode and retention you can justify, not the maximum the software allows.
• Signed-in visitors. If your site sends visitors’ email addresses to the beacon, those are personal data stored in your indexes. Identity & signed-in.
• Automated decisions. Loghound classifies traffic; it does not act on it. If you wire a verdict into something that blocks people, that is your automated decision, and the reason codes exist partly so it can be explained.

1. Do the log files first. Loghound is downstream of them: deleting from the index while the original line is still on disk means it can come back.
2. Find the records by address in Sessions, and remove them from your two Loghound indexes with Delete By Query in the Opensolr control panel. Loghound itself never deletes on request. This works in full and truncated mode; in hashed mode the subject’s records cannot be identified, which is by design and worth saying in your answer.
3. Stop new records for that address with an exclusion on Client address. A matched request is never stored, on either plane.

A text you can adapt for your visitors: Text for your visitors.