The spec was one paragraph long and I wrote it myself. The template library on a site I run was going to get a fillable online version, and the online version would be gated behind a verified email address, with answers stored on the server so that a user could close the tab on Tuesday and pick the work up on Thursday. Anyone who has run an agency site will recognise the shape. The templates are the bait, the email address is the catch, and the saved answers are the reason the user comes back to a domain they would otherwise forget.
I dropped the server before a line of it was built. The reason is the subject of this piece, and it applies to most calculators, audit tools and fill-in-your-numbers sheets that agencies publish as lead magnets, including several I have built for other people.
The spec that looked fine
The site already had the pieces. A magic-link email flow existed for another tool, so verifying an address was a solved problem, and adding a table of saved answers keyed to a user id is an afternoon of work for anyone who has a database attached to a site. The lead-generation case was the standard one. A user who types their situation into a template has told you what they are working on, and a user who comes back to finish it has told you they are serious, and both of those are signals a sales team would pay for.
Nothing in that paragraph is wrong as a description of how lead magnets work. What it leaves out is any description of what the user would be typing, which is the part I had not read closely, because I had written the templates months earlier for people to print and fill in on paper, and on paper the question of where the answers live does not arise.
What the templates actually ask for
I opened the templates as a user would and read every field. Two of them settled the matter.
The first is a client brief for a marketing lead who has just taken on an account. It asks the user to record the client’s commercial reality, in those words, and the fields under that heading are gross margin by product line, the revenue target for the year and the gap to it, which channels are failing and why the client thinks they are failing, and which contracts or relationships the client is worried about losing. A marketing lead who fills this in honestly has written down the three or four things their client would least like a competitor to read.
The second asks what the client knows that cannot be looked up. It is the section of the template I am proudest of, because it forces a marketer to separate the client’s actual expertise from the generic claims on their homepage, and the answers it produces are things like the real reason a product is priced the way it is, which supplier relationship makes the margin possible, and what the founder learned from the last business that failed. The template works because the answers are specific and private. A version of that template that stores its answers on my server is a version that collects the specific and private thing and keeps it.
Put those two together with the spec and the site becomes a place where marketing professionals deposit confidential information about businesses that are not theirs, on a server that belongs to me, under a privacy notice written for a newsletter signup. The email address, the one thing the spec was designed to capture, is the least sensitive field on the page.
Whose data it is
Two separate problems sit inside that sentence, and it helps to keep them apart.
The first is confidentiality, and it has nothing to do with privacy law. A marketing lead who works for an agency almost certainly has a confidentiality clause in their contract with the client, and an in-house marketer has one in their employment terms. The moment they type the client’s margin into my tool and my tool sends it to my server, they have disclosed the client’s confidential information to a third party, which is me, and I have no contract with the client, no obligation to protect it, and no way to be sued for losing it except through the person who typed it. If my server is breached, or a contractor with database access copies the table, or I sell the site and the buyer reads the backups, the person who trusted the tool is the one in breach. I did not want to build something that puts its own users in that position, and I did not want to be the third party in that chain.
The second problem is personal data, and this is where the Digital Personal Data Protection Act 2023 applies. A margin figure on its own is not personal data. A margin figure recorded against a named sole proprietor is, because it relates to an identifiable individual. A note that says the founder is worried about losing a particular contract is personal data about the founder. A field that asks who at the client makes the decision, and what they care about, is personal data about that person. Enough of the fields in these templates would routinely be filled with names, roles and opinions about identifiable people that I have to treat the stored answers as containing personal data, even though the templates never ask for a name directly.
Under the Act, the entity that decides the purpose and means of processing is the Data Fiduciary, and an entity that processes on a fiduciary’s behalf is a Data Processor. [VERIFY: definitions in section 2 of the Act.] It is not obvious which of those my site would be. If I store the answers so that the user can come back to them, I am processing on the user’s behalf and look like a processor, but the user is an individual marketer rather than a fiduciary with a contract, and I decided to build the storage, chose what to store, and would use the fact of storage for my own lead generation, all of which are the choices a fiduciary makes. The Act makes the fiduciary responsible for the processor’s compliance and requires a valid contract between them, which I would not have had with anyone. [VERIFY: section 8(2).] Whichever label applied, the obligations would have landed on me, and I had built nothing to meet them.
What DPDP requires, in plain terms
I am not a lawyer and the Act is new enough that most of what follows has not been tested in front of the Data Protection Board. Read it as a builder’s summary of the sections that bear on a tool like this, with the section numbers marked for checking.
| Obligation | What the Act says, roughly | What it would have meant for the tool |
|---|---|---|
| Consent | Consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action. [VERIFY: section 6.] | A consent step for the user, and no basis at all for consent from the client whose data is being typed in, because the client is not in the room. |
| Notice | Before or at the time consent is sought, the fiduciary gives notice of what data is collected, for what purpose, and how to withdraw consent or complain. [VERIFY: section 5, and the notice contents in the 2025 rules.] | A notice describing every category of answer the templates collect, written before I knew what people would type. |
| Purpose limitation | Data is processed only for the purpose the principal consented to. [VERIFY: section 4 and 6.] | Storing answers so a user can resume is one purpose. Reading the answers to qualify leads is another, and would need its own consent. |
| Retention and erasure | Data is erased when the purpose is served or consent is withdrawn, whichever is earlier, and on request. [VERIFY: section 8(7) and section 12; the 2025 rules add retention periods for specified classes of fiduciary.] | A deletion schedule, a way for a user to erase everything, and no answer for the client, who cannot ask me to delete something they do not know I hold. |
| Security and breach notification | Reasonable security safeguards, and on a breach, intimation to the Board and to each affected principal. [VERIFY: section 8(5) and 8(6); the 2025 rules set the timing and content of the intimation.] | A breach of that table would mean notifying users about a leak of their clients’ data, and I would have no way to reach the clients. |
| Penalties | Monetary penalties set out in the Schedule, with the highest tier for failing to take reasonable security safeguards. [VERIFY: Schedule to the Act; the figures usually quoted are up to Rs 250 crore for security failures and up to Rs 200 crore for breach-notification failures.] | The number matters less than the fact that the exposure is unbounded by the value of the leads. |
The 2025 rules, notified in November 2025 with phased commencement, add detail on the notice, on consent managers, on breach intimation timing and on when data must be erased and how much warning the principal gets before it is. [VERIFY: notification date and the commencement schedule of the Digital Personal Data Protection Rules 2025.] None of that detail changes the shape of the problem. Every one of those obligations attaches to the act of storing, and none of them attaches to a page that stores nothing.
The design decision
So the tool stores nothing, anywhere, and I mean that in the literal sense that can be checked in a browser’s Network tab. The fillable version of each template is a static page. The fields are ordinary form inputs. Every keystroke is saved to the browser’s own localStorage under a key for that template, and when the user comes back on the same browser the fields are refilled from that key. Export is by printing the page to PDF, which every desktop and mobile browser can do without a server, and the print stylesheet hides the navigation and lays the answers out as the paper version would. No request leaves the page after it loads.
The autosave is a few lines and I include it because the whole argument depends on there being no catch hidden in the implementation.
const KEY = "template:client-brief:v1";
const form = document.querySelector("form");
function save() {
const data = Object.fromEntries(new FormData(form));
localStorage.setItem(KEY, JSON.stringify(data));
}
function restore() {
const raw = localStorage.getItem(KEY);
if (!raw) return;
const data = JSON.parse(raw);
for (const [name, value] of Object.entries(data)) {
const field = form.elements[name];
if (field) field.value = value;
}
}
form.addEventListener("input", save);
document.querySelector("#clear").addEventListener("click", () => {
localStorage.removeItem(KEY);
form.reset();
});
document.querySelector("#print").addEventListener("click", () => window.print());
restore();
The page is served with a Content Security Policy that forbids the two ways a page can send data out, so that the promise holds even if a script I did not intend to ship ends up on the page.
Content-Security-Policy: default-src 'self'; connect-src 'none'; form-action 'none'
connect-src 'none' blocks fetch, XMLHttpRequest and beacons, and form-action 'none' blocks a form submit to any URL, so the only ways for a value to leave the page are the ones the user performs themselves, printing or copying. A reader who does not trust me can open the Network tab, fill in a template, and watch nothing happen. That is the check I would ask a vendor to let me perform on any tool that claims to be private, and almost none of them can pass it.
What it gives up
I want to be plain about the cost, because the browser-only version loses three things the spec was built to get.
The first is lead capture. The tool captures no email address, ever, and no name. The templates are among the most visited pages on the site, and the fillable versions will be used by exactly the people the site exists to reach, and I will not know who any of them are. A visitor who wants the newsletter can sign up on the page like anyone else, but the tool itself contributes nothing to the list. On a site whose commercial purpose is to be found by marketing heads who might hire me, that is a real loss, and I would not pretend the value of it is small.
The second is cross-device resume. localStorage belongs to one browser profile on one device. A user who starts a brief on their office laptop and opens the page on their phone gets blank fields. The paper answer to this is the same as it was before, which is to print the PDF and carry it, and the honest answer is that the server version would have been better at this and I chose not to build it.
The third is analytics on answers. I would have liked to know which fields people leave empty, which templates get finished, and what a typical margin figure looks like in the businesses my readers work with. That last item is precisely the thing I have no right to know, and losing the first two along with it is the price of not building the collection in the first place. I still get page views and print-button clicks, and that is enough to tell which templates earn their place.
The trade
Against those three losses the tool gets one sentence, which now sits at the top of every fillable template. Nothing you type here leaves your browser.
No competing tool I have looked at can print that sentence truthfully, because the competing tools are built to the spec I started with. The marketing lead who fills in a client brief on my site can do so without breaching the confidentiality clause in their own contract, without adding a third party to the client’s data, and without wondering what happens to the answers when the site changes hands. For the audience this site is for, people who handle other businesses’ numbers for a living, that is a stronger reason to use the tool than a saved session would have been, and I think it is a stronger reason to remember the site than an email address I collected and then had to justify holding.
The liability on my side is zero, in the plain sense that there is nothing to breach, nothing to delete on request, nothing to notify anyone about, and no privacy notice to write beyond a sentence that is checkable. The gated version can still come later. The magic-link email verification already exists on the site, built for a different tool, so only the storage half would be new, and if usage of the fillable templates ever justifies it I will write the notice, build the erasure path and decide whether I am a fiduciary or a processor before the first row is inserted, rather than after.
The consent field that defaulted to true
The same review turned up something smaller on a different part of the site, and I include it because it is the kind of thing that survives in a codebase for years.
The signup schema for one of the site’s tools had a privacy opt-in field, and the field had a default value of true. A user who submitted the form without touching the checkbox was recorded as having consented. Under the Act, consent has to be a clear affirmative action by the principal, and a pre-ticked box is the standard example of what that phrase excludes, so every consent recorded through that form since it launched was one I could not have relied on if asked. [VERIFY: section 6(1) wording.] The fix was a one-line change to the default and a migration that set the existing records to false, which means the list built through that form is treated as unconsented until each person on it ticks the box themselves. That cost me a portion of a list. It was not a list I was entitled to.
A checklist for anyone running a lead magnet
If you publish a calculator, an audit tool, a benchmark or a sheet that asks visitors to fill in their numbers, answer these six questions before the next campaign sends traffic to it. The exercise takes an hour and I have yet to do it on a client’s site without finding at least one answer nobody had.
| Question | What a good answer looks like | What usually turns up |
|---|---|---|
| What do you collect? | Every field listed, including free-text boxes, with the fields that could contain a third party’s information marked. | The list was never written down, and the free-text fields hold whatever people type. |
| Whose data is it? | The visitor’s own, or their employer’s, or their client’s, decided field by field. | Assumed to be the visitor’s, when most of it describes someone else. |
| Where is it stored? | A named system, a named region, and a named list of who can log in to it. | The form plugin’s database, a spreadsheet integration, and an email notification to three inboxes, none of which anyone counted. |
| When is it deleted? | A retention period tied to the purpose, enforced by a job, with a way for the visitor to ask sooner. | Never, because nothing was ever set up to delete it. |
| Who can read it? | The people who need it for the stated purpose, and nobody else, with contractor and agency access reviewed. | The whole sales team, a freelancer who left, and whoever holds the plugin vendor’s support login. |
| What does your privacy notice say? | It describes these fields, this storage, this retention and this access, in words a visitor can check. | It describes cookies and the newsletter, and was copied from another site. |
| If the answers to the first two questions show that the tool collects information about people who are not the visitor, the rest of the checklist gets hard very quickly, because there is no clean way to give notice to, or get consent from, someone who does not know your tool exists. The browser-only pattern is the way out of that, and it is cheaper to build than the version with the server. |
Where I could be wrong
The Act is new and its rules are newer, and the Data Protection Board has issued few decisions that would show how the sections I have summarised will be read in practice. It is possible that a tool storing a marketer’s working notes would be treated more leniently than my reading suggests, or that the processor label would apply cleanly and shift the obligations to the user. I have marked the section numbers for checking, and anyone building the stored version should get the reading confirmed rather than rely on this.
A reader who runs a lead-generation site may judge the loss of email capture too high, and on their numbers they may be right. If a gated template is the main source of qualified leads for an agency, the answer may be a gated version that stores only the email address and a completion flag, and keeps the answers in the browser. That splits the difference and I would not argue against it.
localStorage has weaknesses of its own that the server version does not. On a shared or public machine the answers persist for the next person who opens the page, which is why the tool has a clear button and a notice about it, and a browser that clears site data on exit will lose the work. Anyone who wants the guarantee to hold on a shared device has to press clear before they leave, and some will not.
I have also assumed that nobody on my side will later add a script to the page that reads the form. The Content Security Policy makes that harder, and a reader can verify the current state in their Network tab, but neither is a substitute for the discipline of not building the collection.
Sources
- Ministry of Electronics and Information Technology, The Digital Personal Data Protection Act, 2023, https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
- Ministry of Electronics and Information Technology, Digital Personal Data Protection Rules, 2025, https://www.meity.gov.in/data-protection-framework [VERIFY: link to the notified rules on the MeitY or eGazette site]
- MDN Web Docs, Window.localStorage, https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
- MDN Web Docs, Window.print(), https://developer.mozilla.org/en-US/docs/Web/API/Window/print
- MDN Web Docs, Content-Security-Policy connect-src directive, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src
- MDN Web Docs, Content-Security-Policy form-action directive, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action