A scan event looks like telemetry until a regulator reads it. It carries a timestamp, a device fingerprint, often an approximate location, and sometimes an identity a person chose to attach. Under the GDPR that combination can qualify as personal data. Under India's Digital Personal Data Protection Act it can as well. A product intelligence system logging scans at consumer scale is, in many jurisdictions, a personal-data processing system, and it should be designed like one.
This piece summarises what the major regimes ask of a scanning system, then describes the two structural answers we built into secQR: collect less, and let you decide where the system runs.
What the regimes ask
The GDPR applies to the personal data of people in the EU wherever the processing organisation sits. It asks for minimisation, purpose limitation, honest notice, and care with cross-border transfers. A scan log with location and device data sits squarely inside its scope.
HIPAA is narrower and sharper. It governs protected health information held by covered entities and their business associates in the United States. Most authentication scans never touch it: confirming a medicine pack is genuine requires nothing about the person holding the pack. The moment a flow links a code to a patient, a prescription, or a treatment, HIPAA's access-control and audit expectations arrive with it.
Data-localisation mandates are the third family. Several jurisdictions require certain classes of records to be stored, and in some cases processed, within the country. For a scanning system the operative question is blunt: where does the scan record physically live, and under whose law can it be compelled.
A scan event is a record of a person, at a place, at a time. Design for that sentence.
Minimisation comes first
We made two decisions early. Location permission at the scanner is optional, and verification works without it. And no personal identity is collected at scan time unless the person chooses to provide it, say for a warranty registration or a grievance report. An anonymous scan produces an event, and an event with less in it is a smaller liability for everyone who stores it.
Minimisation has a cost worth naming. Coarser location means coarser territory analytics; a heatmap built from network-inferred regions will never resolve to a neighbourhood. We accept that trade, because the alternative is holding precise movement data on consumers who only wanted to check that a pack was genuine. Retention is configurable by record class, so scan logs age out on the schedule your policy sets instead of accumulating by default.
Deployment choice is the structural answer
Picture a hospital group that wants scan verification on surgical consumables. Its counsel will ask one thing before any feature demo: where the records live. secQR answers with a deployment decision rather than a contractual promise. Run it in the multi-tenant cloud for speed. Run it as a dedicated instance in a private cloud, under your keys and your network controls. Or run the complete platform on-premises, inside your own data centre, where no scan record crosses your perimeter.
The architecture underneath comes from the KEZEL® platform, whose rule is move the work, not the data. Policies define the boundary, workflows travel to where the data sits, intelligence runs inside, and results are released under policy. Residency stops being an assurance you must audit in a vendor's paperwork and becomes a property of where you chose to run the system. For the managed deployments, the platform is SOC 2 Type II attested (2025), with encryption in transit and at rest.
The limits of architecture
The fair objection to all of this is that architecture cannot discharge legal obligations, and the objection is correct. secQR supports compliance work; the compliance itself remains yours. Lawful bases, notices, impact assessments, records of processing, and breach procedures belong to your data-protection officer and your counsel. What the platform contributes is a defensible position on the two questions architecture can settle: what is collected, and where it lives.
On-premises deployment carries its own bill, and it belongs in this accounting. Patching, capacity, backups, and access discipline shift to your teams, and an auditor will examine your operating practice as closely as our software. For organisations without that operational depth, a private-cloud instance under your own keys is usually the honest middle ground.
The concrete next step for a regulated deployment is a data-flow diagram with one boundary drawn on it. If every scan record sits inside a boundary you operate, the conversation with your regulator starts from a different place.
Regulatory summaries are for orientation only and are not legal advice.