08 October 2025
I recently did a security review for an international company with a niche expertise in a certain type of data management. They asked me to help them to secure a portal that sliced data into digestible widgets for consumers with specific interests.
I started the meeting with the most obvious of questions: “What are you looking to secure?” A simple question, to be sure, but the outcome of that question was a conversation that lasted several hours. There were about six of their executives in the room at the time and the most amazing thing was how their opinions differed on the answer to the question. One said that he just wanted to secure the portal. When I asked him what that meant, he said that only authenticated users could get access to the data. Did this mean that once authenticated all users could get access to all of the data? Of course not, it should be role based. Okay so if someone had the role they could see all of the data of a certain type, or was there a limit? What did that limit look like?
The longer we talked, the clearer it became; they had never really thought through their data assets in detail. The traditional role-based model was nowhere near precise enough for what they needed. And the developers, shifting uncomfortably in their chairs, realised the requirements taking shape in the room were out of reach for the application as it stood.
Unfortunately, the review in this case, was too late. The right time to think about this would have been when conceptual architecture was being put together. If we’d done that, we could have identified the big picture early: the different places data might live, how it would arrive, the destinations it could be sent to automatically, the rules for describing it, the way it would be organised into distinct areas, and finally the data itself. Even this simple sketch, is a skeleton of a conceptual architecture — in a language that everyone in the business can use to talk about security.
To make it more concrete, we could have rounded out the concepts. The places data lives may have become repositories. The routes it travels to get into the system could have been feeds. The places it goes out to — or connects from — could have been terminals. The descriptive metadata might have been registration models. The collections of all these things, set up for a specific purpose, could have been domains. And the actual pieces of data? Inputs.
They start out as words, but they become meaning laden concepts and security stops being vague and out of the reach of non-technical people. A repository can be encrypted. A feed can be signed to prove it hasn’t been tampered with. A terminal can be restricted to trusted partners. A registration model can be locked so only trained staff can handle certain types of data.
In this company’s case, the conversation was happening too late. But for anyone building something new, this is where security really begins — not with firewalls or authentication screens, but with a clear, shared understanding (in ordinary English words) of what you are building and what you are protecting. Without that, you’re securing shadows.
