Personas are a valuable tool to use in modelling and understanding the needs, habits and behaviours of users and other engagement targets when developing tools, policies and process, as Ross Stapleton-Gray, Ph.D., CISSP explains.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
It’s crucial for security to be “in the room” during key decisions, where its perspective can reduce risk or reveal opportunities. But for a small team, that’s nearly impossible; security concerns can surface in almost any context. This challenge is amplified in distributed organizations, where even the best collaboration tools can’t prevent teams from being left “out of the loop.”
Training on security awareness can help, generally. So can promoting both Security and Privacy by Design as policies, to encourage a bias towards building security into products and services, or at least an awareness of where it might be absent in various other areas of organizational planning.
In the spirit of meeting developers where they are, I suggest cloning yourself: insert a stand-in for security into the company’s existing design framework by championing a persona for non-functional requirements.
Personas Explained
A persona is a fictional but realistic instance of a typical individual: a vivid, memorable representative of a set of interests. In design, a persona normally represents an end user in the market or role the company cares about. To develop the persona, it is typically fleshed out with backstory.
For example: “As a Customer Success Manager, Jane wants a repository of all her team’s customer interactions. Jane has been in customer success for seven years, starting as a support rep and working her way up. She leads a mid-sized team at a fast-growing SaaS company, where churn has become a hot topic. She’s known for her empathy and sharp memory, but lately feels overwhelmed by scattered notes, forgotten follow-ups and a lack of visibility across her team’s interactions. Quote: Everything our team does should build trust—but that’s hard when we can’t even see the full picture.”
The purpose of a persona is to remind the developer of a product or service for precisely whom it is that they’re building. In this case, it enables them to more readily imagine the functional requirements of what they are building, to make sure they address “Jane’s” concerns: to help her organize, visualize a bigger picture, etc.
As such, the use of personas is very common – utterly normal. But here’s the thing: I’ve seldom seen teams create personas to champion non-functional requirements.
Personas for Non-Functional Requirements
While functional requirements describe what a particular product or service should do for the end user, non-functional requirement describe how that product or service should work. For example: “For GDPR-compliance purposes, it should not retain unnecessary personal data”.
This ‘how’ may be of little concern to the end user, but it’s critically important to the organization. That’s because it’s where risk lives – from security breaches caused by misconfigured integrations to legal liability from mishandling user data.
At my own organization I suggested introducing a persona - Clio (cribbing initials from the various supporting team roles of Compliance, Legal, InfoSec and Operations) – to help ensure we consider an important range of non-functional requirements. This is because, when the security team is small, it can’t be everywhere at once. Personas, acting as proxies, give security a seat at the table – even when no one from the team is in the room.
Just like our fictitious Jane, Clio has her own backstory: “As the Director of Governance, Risk and Compliance (GRC), Clio wants any new service to be inherently secure, compliant and auditable by design. Clio has 12 years of experience in corporate law and risk management, holding a JD and certifications like CIPP/E. She began her career in the highly regulated financial sector before moving into tech, where she has managed the company’s SOC 2 and GDPR certifications. She’s known for being meticulous, pragmatic and proactive, focused on enabling the business to grow safely. Lately, she feels her diligence is perceived as a bottleneck, as she pushes back against teams who prioritize speed over security and process. Quote: ‘Features get customers in the door, but trust is what keeps them here. Trust is built on a foundation of security and integrity that you can’t just bolt on later.”
I would love to tell you that Clio has been an overwhelming success already. In reality, evangelizing security in most organizations is usually more marathon than sprint. However, a year after proposing “The case for Clio” on an internal blog, she is on the brink of implementation.
Clio is likely to have company, in the guise of multiple “archetypes” – a somewhat blander version of personas, focused on the role and less fleshed out. But, along with three “archetypes” representing users at different levels from the strategic to the tactical, our design team is willing to engage with a fourth archetype, addressing exactly the concerns that my Clio had been talking up.
Ideally, I’d like to see Clio “at the table”, whenever systems are scoped and designed and regularly thereafter. This would see her present during project prioritization and also as a witness and commentator, even in security incident post mortems: “Could we have built in more safeguards against this, or a means to be better aware if it happens again?”
If she’s there in spirit, whether as archetype or persona, I’ll have done well enough by her and through her to ensure that the voice of security, compliance and related concerns are better heard, as well as heard earlier in the development process too. Watch this space.
Ross Stapleton-Gray, CISSP, has over 30 years in the technology, government, non-profit and education sectors. He has held various research, compliance and cybersecurity roles, with responsibility for establishing or maintaining security and compliance programs and teams. His work spans work in pharmaceuticals, data engineering and research tools start-ups.
