An awareness project gets approved twice. The first time by the security team, which looks at architecture, integrations and controls. The second time by whoever answers for the organization’s personal data, and that person asks something else entirely.
That second conversation always arrives with the same four questions. Which of our data ends up there, where it is stored, for how long and who gets to look at it. They are answered with a retention period, a region name or a mechanism. When what arrives is a statement of good intentions, the answer does not exist yet.
What follows is how we answer those four questions on awareness program data retention, using published periods and regions. The exercise works for evaluating any platform.
What data enters the program and what data does the program generate?
There are two distinct sets and it pays not to mix them, because their origin, owner and risk differ.
The first comes from the organization and amounts to three fields, first name, last name and email address. It is the minimum for an audience to exist and for a result to be attributable to someone. Any other attribute, such as department or job title, only enters if the organization wants to segment by it. None of it is created by the platform, it arrives from the corporate directory through import or synchronization, and its owner remains the client.
The second is generated by the measurement and did not exist before. It is made up of a delivered message, an open, a click, a report through the button, a completed training with its date and topic, and a risk score per person, per group and per organization. That set usually falls outside the privacy committee’s analysis and is the more delicate of the two, because it describes the behavior of an identifiable person facing a stimulus. Building a reliable human risk score starts by deciding which signals belong in there and which do not.
The distinction has a practical consequence. On the first set you discuss volume and synchronization. On the second you discuss purpose, retention and visibility, which are the three things a data protection officer will want in writing.
Does the platform store the password someone typed into the simulation?
No, and the mechanism matters more than the assertion. It is the question I have been asked most often in implementations, and the worst way to answer it is to ask for trust.
Phishing simulation traps are configured either to allow or to block credential entry. When they block it, the employee who lands on the simulated site finds the password field disabled, and the username field accepts a single character. There is nothing to type and therefore nothing that travels.
When they allow it, the form can have any number of fields, but only two enter the decision, user and password, identified by the name attribute. On submission, both are checked for content. If both carry data, the campaign records it as data entered, regardless of what was typed. If either is empty, the page reloads. The data travels over HTTPS and is never stored, analyzed or manipulated.
The result is a binary metric. The platform knows that a person handed over a credential, never which one. That is enough to measure the behavior the simulation went looking for, and it removes the uncomfortable question about what would happen if that database leaked. The same logic applies to what needs to be configured before you trust a click rate, a metric is useful when you know exactly what produces it.
Where does that data live and which part of the path leaves Europe?
The platform is located in Dublin, Ireland. The region is EU (Ireland) eu-west-1. Databases use PostgreSQL with high availability and each client has its own schema, separate and independent from the rest. A shared schema holds the predefined content, and each organization’s confidential information lives in its own, which is the same isolation principle behind multitenant operation.
At rest, databases are encrypted with AES-256 and the keys are managed by Amazon through its key management service. In transit, all communications go over TLS 1.2 and 1.3. Development and testing environments are independent from production, and the production database is never used in another environment.
So far the answer sounds like “everything is in Ireland”, and it is worth pinning down how far that goes. Storage, the runtime environment and the log management tool are there. Mail sending is split between two providers, one in that same European region and one in the United States. User import and authentication, and notifications to employees, rely on services operating in the United States. Auth0 authentication stays in Europe.
None of that is a discovery, it is published in the data processing policy, which also details the specific data each provider touches and gives clients thirty days to object to a new subprocessor. Transfers outside the European Economic Area are covered by standard contractual clauses or by binding corporate rules, per the processing agreement.
The useful question does not get a yes or no answer. It needs specifics on which data leaves, where it goes, for what function and under which legal instrument. A vendor answering the first version with a flat yes probably has not read its own architecture, and that is information too for anyone putting together a vendor security questionnaire.
What data retention period applies to each item?
There is no single period. Several clocks run in parallel, and none of them says “forever”.
- Backups. Daily, encrypted and separated per client, stored redundantly in Amazon S3 and Google Cloud Storage EU
eu-west-1instances. They are kept for 90 days and tested with periodic controlled restores. - System logs. Held in a centralized register for one year, for later analysis if needed.
- Service data when the subscription ends. The client has 30 days to export the information or request its deletion. After that period all service data is deleted.
- Audit records. No separate published period. They are part of the service data, so their exit is governed by the same thirty-day window as the point above.
There is a calculation almost nobody runs. A vendor’s retention periods are the ceiling on what your organization can promise its own committee. If your internal policy says a campaign result is kept for twelve months, and the vendor’s backup keeps it another ninety days from the last copy, the real retention period is the sum of the two. That is the number that belongs in the internal policy.
Who looks at an employee’s result, and what gets recorded about that look?
First the split of roles, because it defines who decides. SMARTFENSE is the controller of personal data belonging to its own clients, partners and employees. For personal data that is the client’s responsibility, it takes the role of processor, and always processes on that client’s behalf and instruction. In practice, the decision on who sees a person’s result inside an organization stays with that organization.
What the platform does contribute is the log. Every activity by end users, administrative users and the system is recorded. The log shows which user completed which content, on which date and on which topic, the creation or deletion of a campaign, which cannot be erased or hidden, and also when an email went out, when an automatic user import ran and when information was exported. Records are detailed and unalterable, protected by an anti-tampering system, and cannot be modified in any way.
That design is usually defended as an audit requirement. Its most important effect points the other way. The log protects the people being measured, because exporting a person’s result also leaves a trace, and the administrator who takes a report away is recorded as precisely as the employee who clicked. A program that can show who looked at what is in a better position to sustain the evidence it will be asked for than one that can only show results.
What happens when someone asks for their data to be deleted?
The GDPR right to erasure is not absolute. Article 17 grants the right and its paragraph 3 lists the cases where it does not apply, among them compliance with a legal obligation that requires processing that data.
For whoever is choosing a platform, that becomes a concrete capability. You need to honor a person’s request without breaking the evidence an audit will ask for later, and that takes something finer than a button that deletes everything. What is kept, and on what legal basis, is decided by the organization as the controller. What the platform has to provide is the execution.
What do you take with you the day you decide to leave?
The final test of any data agreement is the exit, and it is measured in periods.
When the service ends there are 30 days to export the information or request its deletion, and the export format is handled by the platform API, which exposes the same data areas the program uses while it is alive. For a confirmed data breach, notification arrives within 48 hours. All of it sits in the data processing agreement, a public document you can read before signing.
It is worth looking at what exactly you take. A three-year program produces a history of campaigns, completed trainings and scores that is, at the same time, the compliance evidence for those three years. Leaving without that history means starting the next audit from zero, with the burden of proof against you. That conversation is best had at signing, while it is still a negotiable clause.
Frequently asked questions
What personal data does an awareness platform need?
Three fields, first name, last name and email address. That is the minimum for an audience to exist and for a result to be attributable to someone. Any other attribute, such as department or job title, only enters if the organization wants to segment by it. That data comes from the client’s corporate directory, the platform does not create it. What the platform does create is behavioral data, which did not exist before the measurement.
Are the passwords employees type into a phishing simulation stored?
No. In traps configured without credential entry, the password field is disabled and the username field accepts a single character. In traps that allow entry, the platform only checks whether the user and password fields carry data, and records the result as data entered regardless of what was typed. That data is not stored, analyzed or manipulated.
Where is SMARTFENSE awareness program data hosted?
Storage, the runtime environment and log management sit in the EU (Ireland) eu-west-1 region, with an independent database schema per client, AES-256 encryption at rest and TLS 1.2 or 1.3 in transit. Other parts of the service operate outside the European Economic Area, and each one is declared with its provider and country in the data processing policy.
How long is awareness campaign data retained?
Retention differs by data type. Backups run daily and are kept for 90 days. System logs live in a centralized register for one year. When the subscription ends, the client has 30 days to export the information or request its deletion, and after that period all service data is deleted.
Can everything about a person be deleted when they ask?
Article 17 of the GDPR grants the right to erasure and its paragraph 3 lists the exceptions, among them compliance with a legal obligation that requires processing that data. Which case applies is decided by the organization, in its role as controller.
If you are evaluating awareness platforms, ask for the four answers in writing before the technical demo. Hosting region, retention periods by data type, split of roles and exit conditions. Ours are published and can be compared against anyone else’s.
Leave a Reply