Do we really not trust our own workforce? Why do we really need an additional API call to mask data?
The team started questioning the need for this as we were progressing toward our first migration of an application from the WebSphere platform to the AWS platform. I was arguing for masking sensitive data before it reached the database layer. We had a requirement to store the note. We did not have a requirement to store sensitive identifiers inside it. A user working on a claim or a policy change writes a note, and in that note they may type an SSN, a driving license number, or a credit card number — and those identifiers are already held in the organization’s own systems of record. The note is new information. The identifiers are not, and a second copy of them sitting in a notes database serves no purpose.
The identifiers a user types into a note are not their own. They belong to the customer. The question was not about the need. It was about the integrity that the organization promised to its customers, and adherence to regulatory compliance.
It’s about preventing liability
It is not that we do not trust our own workforce. No one is judging anyone’s work or questioning the integrity of how they perform within their role and responsibility. Masking is not an insult. We are ensuring that we are not showing a customer’s sensitive information to every user of the application who has access to open it. It’s not about insult — it’s about preventing a liability.
When we integrated our UI with the API in the test environment, we entered an SSN-shaped value into the free-form text — a synthetic one we made up — and got the same value back, unmasked. It raised a question. I went to our product owner, who had spent fifteen years testing applications in this domain. He could not test ours yet, because it was still in development. But he pulled up his own archived test artifacts from a different application in the portfolio, and showed me what the same class of identifier looked like after masking.
People are trained, but they still mess up, and there is no restriction we can impose on user action on the UI screen. We figured out the best fix is to add an API call that masks the sensitive data before it even hits the database.
In the real world, nobody wants to see their own personal or sensitive information repeatedly on a UI screen. For example, we don’t see our own complete bank account number every time we log into a bank website. It comes masked, showing just the last four digits. So why does someone else need to see, read, or print that information every time they open a customer’s ticket or claim? We were also providing a print feature, so it does not even stay on the screen — it can end up on paper. And seeing sensitive information over and over can make someone memorize it without meaning to. We will not disclose it to anyone intentionally, being responsible people. But why see it repeatedly when we don’t need to?
A warning symbol with a label in red font on the UI screen sends a strong alert signal to the brain that helps the user be cautious while entering any information into a free-form text field. The signal not only increases consciousness, but also slows reflex action, giving the user a moment to pause while entering details into the field.
Writing an internal masking algorithm
As discussed within the team, some argued that since we provide training, the user would be cautious, while others argued that we provide the warning label — why wouldn’t the user read it? Some came up with: why do we need an additional API call to mask it, let’s implement an internal masking algorithm?
It took a day and a half to build a POC of the internal algorithm. On the second afternoon we demoed it to the team: enter any value, get a masked value back. We asked them to break it. Within about forty minutes, by feeding in various inputs and studying the outputs, they had the pattern. They understood the drawback themselves, and agreed the internal algorithm would not work — go with the enterprise service.
During one of those arguments, I took a coffee break and thought about it differently. If a developer writes a logger.info and prints the values we are inserting, that sensitive information is now in the logging stream. And once it is stored in the database as it is, it is exposed to every downstream system that reads it — the analytical reports, the marketing extracts, and whatever audit trail the database keeps that we never see.
Data classification should have equal priority as architecture in any application. We treated it as a low-priority task that could happen in parallel with development, and that was wrong. We need to understand our data as much as we need to understand our architecture.
