Consent Record Retention for Electronic Consent — What ISMS-P Checks, and Snapshotting the Wording Customers Saw

The baseline for consent record retention is spelled out in Korea's ISMS-P Certification Criteria Guide: record the date and time of consent, the consent items, who consented, and the method, and keep that record until the personal information is destroyed. Sector-specific retention laws stack on top of that. Still, I don't think the baseline is enough on its own. It preserves when someone agreed, but not what they saw when they agreed. That's why I think the most reliable approach is the snapshot: copy the consent wording exactly as rendered on screen and store it alongside a hash.

Here's the order this post follows. First, what Korean law and ISMS-P require of consent records, what auditors look at, and how to set the retention period. Then, the gaps in the common "store the outcome only" structure, and how to design electronic consent records as snapshots. The later sections come from actually moving from outcome storage to snapshot storage. This isn't a story about one particular system. It's about a structure that almost anyone collecting consent electronically runs into.

Consent Record Retention: What ISMS-P and the Law Require

Everything below comes from the statute text on Korea's National Law Information Center and from the Information Security and Personal Information Management System (ISMS-P) Certification Criteria Guide (November 2023). I covered how these criteria are structured in my post on ISMS vs ISMS-P.

What to record and for how long — criterion 3.1.1

The key checkpoints for ISMS-P criterion 3.1.1 (Collection and Use of Personal Information) include: "Are records of consent obtained from data subjects and legal guardians being retained?" The detailed explanation says to keep and retain consent records "so that the legal basis arising from consent to collection and use can be proven," and lists what to record and for how long.

Item	What the guide says
What to record	Date and time of consent, consent items, who consented (guardian details if a legal guardian consented), method of consent, etc.
Retention period	Until the personal information is destroyed, for example after the member leaves

The evidence auditors look at, and defect cases

For the same criterion, the guide lists these as example evidence:

• Online collection forms (website and mobile app sign-up screens, event entries, etc.)
• Offline collection forms (paper membership applications, etc.)
• Consent records (member database, etc.)
• Legal guardian consent records
• The privacy policy

What stands out is that auditors look at the consent records and the collection forms (screens) together. The defect cases cover both sides. Leaving "the right to refuse consent and any disadvantage from refusing" out of the notice, or describing collected items vaguely with "…etc.," are defects in the screen wording. Failing to keep guardian consent records, so the guardian's name and consent time can't be verified, is a defect in the records.

What follows is my own interpretation. You can always show today's screen. But whether the screen a customer saw three years ago included the right-to-refuse wording is something you can't show unless that wording was kept.

How consent must be obtained, and the burden of proof

• What to disclose. Article 15(2) of the Personal Information Protection Act (PIPA) requires notifying the purpose of collection and use, the items collected, the retention and use period, and the right to refuse consent along with any disadvantage from refusing.
• Ask for each item separately. Article 22(1) requires presenting "each matter requiring consent separately so that the data subject can clearly recognize it" and obtaining consent for each.
• Electronic consent means "posting the content." Article 17(2)(4) of the Enforcement Decree lists, as one valid method, "posting the content of consent on a website or similar and having the data subject indicate whether they consent."
• Conditions for valid consent. Article 17(1) of the Enforcement Decree requires all four of the following: the decision is made freely, the content is specific and clear, the wording is easy to read and understand, and there's a clear way to indicate yes or no. This took effect on September 15, 2024. Just before that, on September 12, the Personal Information Protection Commission (PIPC) issued a press release titled "Improving the practice of mandatory consent."
• When consent isn't needed. Under the amended Act, promulgated in March 2023 and in force from September 15, 2023, Article 15(1)(4) covers cases "necessary to perform a contract concluded with the data subject, or to take measures at the data subject's request in the course of concluding a contract." Information needed for a contract can be processed without consent.

The Act names the burden of proof in two places. Article 16(1) puts "the burden of proving that only the minimum personal information was collected" on the controller, and Article 22(3) puts "the burden of proving that the information may be processed without consent" there too. Article 22(3) also requires that information processed without consent be disclosed separately from information processed on the basis of consent, in the privacy policy or otherwise. For processing based on consent, as noted above, the guide says to keep records so the legal basis can be proven.

How Long to Keep Consent Records — Setting the Retention Period

Set the retention period by layering three things.

1. The certification default: until the personal information is destroyed. A consent record is the basis for processing that information, so as long as the information exists, its basis should too.
2. Sector laws: if your business has a financial-transaction element, the Act on Reporting and Using Specified Financial Transaction Information sets the standard at five years after the transaction ends. Check whether your sector has its own retention duty.
3. The period you told customers: under Article 15(2), you state the retention and use period when you ask for consent. What you actually keep has to match that period and what's in your privacy policy. If you change the retention period in your system, update the privacy policy too.

The privacy-policy side keeps moving as well. The PIPC revised and republished its guidelines for writing privacy policies in April 2025, and released another revision in April 2026. It's worth rechecking how you describe retention periods and consent bases against the latest guidelines.

The Gaps in Storing Only the Consent Outcome

Many e-consent systems store only the outcome of consent: a consent flag, a signature image, an IP address, a timestamp. That fills most of the guide's record items. "What did they agree to?" gets answered by opening today's template and working backward. When you first build a system, this feels natural. There's one template, the customer agreed to it, so pointing at the template seems like enough.

The trouble starts as time passes and the template changes. Here's what tends to go wrong in this setup.

1. Editing the template overwrites the original. There's no way to retrieve the wording the customer saw at the time.
2. The link between a consent flag and the item it refers to is loose. Reorder the items or add a new one, and the mapping can drift.
3. For optional items, "declined" and "never shown" look the same. Both end up recorded as "did not consent."
4. Replacing terms that are shown as images wipes out past versions. Once the file is overwritten, it's gone.

In short, when someone consented survives, but what they saw when they consented becomes hard to prove.

How far should "consent items" go?

The guide says to record "consent items," but it doesn't say to record the wording of those items. Still, a record that keeps only the item name loses its value the moment the wording changes. If an item is still called "Consent to receive marketing information" but its body has been rewritten three times, the name alone can't tell you which version a given customer agreed to. If you follow the intent — keep records so you can prove it — I think you end up needing the wording itself.

How to Retain Electronic Consent Records — Designing Snapshots

Split recording across three points — write on render, confirm on consent, backfill at close

If you hang every record on a single request, nothing is left when that request fails. So I split recording across three points. If any one of them fails, the contract still goes through, and the later points fill in for the earlier ones.

Point	What it does	What it means
Render	Records every item drawn on screen as "no response"	This is where the snapshot is fixed. What the customer saw is captured before they sign
Consent	On normal processing, confirms consent/decline and the time for each item	"Declined" and "no response" become distinguishable
Backfill	If the consent confirmation is empty, fills it from the outcome values	Only when it can be confirmed that the template didn't change in between. Otherwise it doesn't fabricate a copy and marks the record "incomplete"

The key is taking the snapshot at render time, not at consent time. Before the customer clicks anything, "this wording was shown to this customer" is already on record. The consent step just layers the response on top.

The condition on the backfill step matters too. Filling gaps from outcome values is convenient, but if the template changed in the meantime, the filled-in record is no longer true. When it can't be confirmed, I chose not to fill it and to mark it "incomplete" instead.

What goes into each row

One item is one row. It's the guide's record items (when, what, who, how) plus the wording and a hash.

• A copy of the item's title and body
• Whether it's required, and which branching conditions actually applied
• A content hash (SHA-256)
• Whether consent was given, consent time, render time
• Access information, render count
• Columns for withdrawal information

I added two more principles. First, record only what was rendered. Even when each order carries different additional consents, writing down exactly what was drawn on screen absorbs them all into the same structure. As new consent types appear, the structure doesn't need to change. Second, don't delete rounds rendered multiple times by a page refresh. Those rounds remain as "shown, but not consented to."

Copies are saved with parameterized queries, so that special characters in the terms text aren't altered during SQL processing. Evidence that changes at the moment it's saved is worthless.

Lookups are built per order, around the question "What did this customer see, and what did they agree to?" "When did this item change?" is a different, template-side question, so it's kept separate.

Editing and deleting templates — "deletion leaves evidence behind" beats "no deletion"

The template-side history matters as much as the customer-side record. When a template is saved, the pre-edit content is kept as history only for items that changed.

Deletion took a lot of thought. I considered blocking it outright — "items customers have consented to cannot be deleted" — but didn't go with that. Block it, and staff turn to a bigger workaround, like swapping out the whole template. So what I chose was a structure that allows deletion as the work requires, but doesn't let the evidence escape.

• Keep the pre-deletion content in the history.
• Preserve any material that customer consents refer to.
• If preservation fails, stop the deletion.

Replacing terms shown as images works on the same principle. New customers get the new material, and material that past consents refer to is preserved.

What I Learned in Practice — Five Things

It only sticks if it never blocks the core business

If a compliance feature gets in the way of closing a contract, it won't survive in the field. So the first principle I set when adding snapshots was this:

• Leave the existing consent and contract flow untouched, and only add recording logic.
• Isolate all recording logic. If recording fails, it logs the failure and the contract goes ahead. Keeping failures from spreading into the core flow follows the same idea as the safety nets in my post on fallback design.
• Have an operational switch that can stop it without a deploy. Pulling rules out of code so operations can change them is something I explained in my post on closed loops.
• Roll it out after business hours, and reconcile consent outcomes against history row counts the next day.

There are more consent paths than you think

It feels like consent comes from one screen, but the call-center path, the customer self-service contract path, and the online application path may run on different engines. Attach recording to just one, and consents from the others still leave only outcomes. Before touching anything, map the code for every path where consent is created, or you'll miss some. I attached the same recording logic identically to each path.

Placeholders — the template text isn't what the customer saw

If a template contains placeholders like "#{CompanyName}" and the substitution happens in the browser, storing the raw template text doesn't match what the customer saw one-to-one. The customer didn't see the placeholder; they saw the substituted result. So I kept the raw text as is and stored the substitution values and the substituted body separately. Before rolling it out, I ran a large-scale automated comparison to confirm that server-side substitution produced the same output as on-screen substitution.

With hashes, it's all about what you hash

A hash only tells you whether something changed. It doesn't tell you what changed or who changed it. That's why the target of the hash matters more. Whether you hash the raw text or the substituted version, and whether you include attached images, changes what that hash can prove. Bundling attached images into the hash can get a bit tricky once you factor in where those files live. It's worth writing down what your hash covers and what it doesn't.

Test records are evidence too

When people test by clicking through manually, nothing records how many times a page was opened or where it was refreshed. So I used automated tests that run only on test-only orders to record each step's screen and the stored results.

What About Consent Collected Before the Snapshot? — Not "Backdating" but "Restoration"

Snapshots accumulate from the day you introduce them. Consents collected before that aren't a backdating problem. They're a restoration problem. The original screens are gone, and what you can do now is reconstruct the wording at the time, based on evidence.

So I'm considering separating these records by name, according to the strength of the evidence.

Type	Condition	What to mark
Current-version restoration	The template hasn't changed since that consent, so the current version is confirmed to be the version at the time	That it's a restored record
Inferred restoration	The version at the time is inferred from circumstances	That it's inferred, and on what basis

Either way, substitution values are recalculated now rather than being the values at the time, so that gets marked too.

There's one principle. Don't stack inferred copies as if they were real ones. Snapshots that were actually captured and records restored later must be visibly distinguishable.

When You Need Snapshots, and When Outcome Storage Can Hold Up

Not every situation calls for the same weight.

• You need snapshots when: consent wording changes often; additional consents vary by order or product; placeholders make the wording differ per person; or there's a real chance you'll have to show consent content in a dispute or a certification audit.
• Outcome storage can hold up when: the wording rarely changes, each version is archived separately whenever it does, and every consent is precisely linked to the version it refers to. But if version control slips even once, your proof for that period breaks.

Snapshots have costs too. The same wording is copied once per customer, so storage grows, and every path that gets recording logic needs verification. Weigh that cost against someday having to say, "We don't know what we showed them at the time."

Wrap-Up — A Consent Record Retention Checklist

When reviewing consent record retention, try starting with these questions.

1. Are the date and time, items, who consented, and method all recorded? (The ISMS-P 3.1.1 baseline)
2. Does the retention period line up with destruction, sector laws, and the period stated at consent and in the privacy policy?
3. Are you storing the outcome, or the screen the customer saw?
4. After editing or deleting a template, can you still retrieve the wording a past consent was based on?
5. For optional items, can you tell "declined" from "never shown"?
6. Do you know every path where consent is created, and does the contract still go through if recording fails?
7. If there are placeholders, is the substituted body kept? What exactly does your hash cover?
8. If you restored pre-snapshot consents, are they visibly distinguishable from real records?

Work like this is important but not urgent, so it keeps getting pushed back. It won't stop a contract today. But the weight of personal data management keeps growing, and for electronic consent especially, consent record retention is moving from outcomes toward snapshots. Unless you deliberately put it on the schedule, you'll find out it's missing on the day you need it.

Official sources referenced: ISMS-P Certification Criteria Guide (Nov 2023) — Personal Information Portal (Korean), Personal Information Protection Act — National Law Information Center (Korean)