For Rimple Kapil, CISSP, CCSP, cybersecurity is not only about stopping something bad from happening. It is also about helping an organisation understand what could happen, what matters most, what controls are appropriate and whether the remaining risk is understood. In other words, a large part of cybersecurity is about assurance and confidence.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
When I tell people I work in cybersecurity, the conversation often goes in a familiar direction. They ask: “Do you stop hackers?” and “Have you ever been involved in a big data breach?” or “Do you spend your day looking for scammers?”
These are reasonable questions. Cyberattacks, scams, ransomware and data breaches are some of the most visible parts of cybersecurity. But after more than two decades working across network, cloud and enterprise security, I have come to see cybersecurity somewhat differently.
Security Starts Before the Attack
Some of the most valuable security work happens long before an attacker gets an opportunity.
In my role as a security architect, I am often involved when a new technology, application, cloud service or business capability is being designed or changed. At that point, there may be no vulnerability, no incident and no attacker. There is simply a proposal.
My role is often to ask questions before the technology becomes difficult or expensive to change. How will users authenticate? Who should have access? What happens if a privileged account is compromised? How are applications communicating? Where does information flow? What happens if a third-party service is unavailable or compromised? How would we detect something unusual?
These questions may not sound as exciting as hunting for a hacker, but they can have a significant impact on the security of an organization.
One example from my experience involved reviewing a solution that appeared to have the expected security mechanisms in place. Authentication was being used, communications were protected and logging was available.
But as I worked through the architecture, I started asking a different set of questions. It was not enough to know that authentication existed. What was actually being validated at each layer? Who was responsible for enforcing access? What happened if a trusted component was compromised? Were the assumptions between components still valid?
The discussion moved from “Do we have authentication?” to “Where is trust established and how is that trust verified?” That was a much more useful security conversation.
It also reinforced something I have seen repeatedly in architecture work: security controls cannot always be evaluated in isolation. The way they interact with the rest of the solution matters.
Security Architecture Is Not About Making Everything Secure
Another lesson I have learned is that the word secure can sometimes create the wrong expectation.
There is no realistic environment where every risk can be eliminated. A security architect is not there to declare that a solution is completely secure. My role is to help ensure that security risks have been considered, appropriate controls have been identified, important gaps are understood and decisions are made with sufficient information.
I have reviewed designs where a statement such as “the data is encrypted” initially sounded reassuring. But then come the questions: How are the keys managed? Who can access them? How are they protected? What happens when they need to be rotated?
The same applies to logging. A platform may generate logs, but that does not necessarily mean the right security events are being captured, protected, monitored or acted upon. An application may authenticate users but that does not automatically mean every API or downstream component is correctly enforcing identity and authorization.
These distinctions matter.
Security is rarely a single checkbox. In my experience, it is about understanding how multiple components, controls, processes and responsibilities work together.
Sometimes an assessment identifies a genuine gap. Sometimes it reveals an assumption that needs clarification. And sometimes the most valuable outcome is discovering that something initially appearing to be a concern has already been appropriately addressed.
Good assurance is not about finding problems for the sake of finding problems. It is about increasing confidence in the security decision.
When Security Becomes a Partnership
One of the most useful experiences I have had is seeing what happens when security is treated as a partnership rather than a gate.
I have worked with delivery teams where the initial expectation was that the security review would be another hurdle to get through. That is understandable. If security engagement happens late, after major design decisions have already been made, security requirements can feel like additional work being imposed on the project.
But I have also seen how the conversation changes when security is involved early.
Rather than asking, “What security controls do I need to add?” the team starts asking, “How should we design this?” instead.
A discussion about identity becomes part of the architecture. A conversation about data becomes part of the product design. Questions about logging become part of operational readiness.
Security is no longer something added at the end. It becomes part of how the solution is built.
For me, one of the strongest indicators that this approach is working is when the delivery team starts identifying security implications themselves. The best security conversations are not necessarily the ones where I identify the most issues. They are the ones where security thinking becomes part of the team's own decision-making.
That, to me, is security-by-design in practice.
The Unexpected Value of Security Champions
One of the positive developments I have seen is the growth of Security Champion communities within delivery and engineering teams. Security Champions can act as a bridge between cybersecurity specialists and the people designing and delivering technology every day.
I have seen conversations become much more productive when someone within a delivery team already understands security principles.
A developer might question whether an API really needs a particular permission. An engineer might recognize that a proposed architecture creates an unnecessary trust boundary. A product team might realize that collecting a particular type of information creates additional security or privacy considerations.
These may seem like small decisions but collectively they can have a significant impact.
The real value of a Security Champion is not that they become the security expert for their team. It is that they help create a culture where security questions are asked earlier. That is why I believe security awareness should go beyond telling people what not to do.
Awareness should help people understand why security matters to the decisions they make every day.
People, Process and Technology Are Connected
Over the years, I have also learned that people, process and technology cannot really be separated.
A technically strong control can fail because a process was poorly designed. A good process can fail because nobody understands their responsibility. And a well-designed technology solution can introduce risk if people use it in ways that were never anticipated.
Access control, for example, is not simply a technology problem. We need to understand who requires access, why they require it, how privileged access is governed and what happens when someone's role changes.
Similarly, logging is not simply a matter of enabling a feature. There needs to be agreement about what should be logged, how those logs are protected, who monitors them and what happens when something unusual is detected.
This is why I see security architecture as sitting at an interesting intersection between technology and business. We translate security principles into practical decisions.
Sometimes the technically strongest option is not necessarily the most appropriate business decision. The objective is not to pursue security at any cost. It is to understand the risk and make a reasoned decision.
Sometimes The Hardest Part Is Asking the Right Question
One of the most valuable skills I have developed over my career is not knowing every answer. It is knowing what questions to ask.
Technology changes too quickly for any security professional to know everything. Cloud platforms evolve, APIs change, AI introduces new capabilities and threats. Organizations adopt technologies that did not exist when many traditional security practices were established.
When reviewing a new solution, I might not immediately know whether a particular implementation is appropriate. But I can ask: What is the trust boundary? What identity is being used? What happens if that identity is compromised? What data is moving across this interface? Who can change the configuration? How would we detect misuse? What assumptions are we making?
Those questions often reveal more than simply checking whether a control exists.
They also encourage the delivery team to think about security themselves. That is where I believe assurance becomes more powerful than compliance.
Compliance can tell us whether something meets a requirement. Assurance asks whether we understand what the requirement means in this particular context, whether the control actually addresses the risk and whether we have enough confidence in the outcome.
Cybersecurity Ultimately Protects Trust
So, what does cybersecurity really protect? The obvious answers are systems, networks, applications and data. But I think there is something bigger underneath all of these. Cybersecurity protects trust.
Customers need to trust that an organization will protect their information. Employees need to trust that the systems they use are reliable. Business leaders need confidence that technology risks are understood before major decisions are made. Engineering teams need confidence that security requirements are clear and achievable.
This changes the way I think about cybersecurity. Our job is not simply to say “no” to technology. Nor is it to create an illusion that risk can be reduced to zero. Our job is to help organizations make better-informed decisions about risk.
Sometimes that means challenging a design. Sometimes it means identifying a missing control. Sometimes it means helping a team understand why an existing control is sufficient. Sometimes it means accepting that a particular risk remains, provided it is understood and managed appropriately.
From Security Awareness to Security Culture
If there is one thing I would like people outside cybersecurity to take away, it is that cybersecurity is not solely the responsibility of the security team.
Security teams provide expertise, guidance and assurance. But security outcomes are created throughout an organization.
The architect making a design decision. The developer writing code. The engineer configuring infrastructure. The product owner deciding what functionality is required. The employee deciding how to handle information. The leader deciding which risks are acceptable.
All these decisions contribute to cybersecurity.
The strongest security culture I have experienced is not one where everyone is afraid of making a mistake. It is one where people are comfortable asking: “Have we considered the security implications?”
That question can sometimes be more valuable than another security control.
After more than two decades in cybersecurity, I have become less interested in the idea of security as simply building higher walls around technology. I am more interested in whether we are helping organizations understand the risks they are taking, make informed decisions and build security into the way they operate.
We may start conversations by talking about hackers, scams and breaches. But ultimately, I believe cybersecurity protects something much broader.
It protects the confidence to operate, innovate and make decisions in an increasingly digital world.
Rimple Kapil, CISSP, CCSP, has 21 years of experience in telecoms, cloud platforms, network infrastructure and cybersecurity architecture. She has held technical and architecture roles, with responsibility for designing, reviewing and assuring secure solutions across cloud and on-prem environments. Her cybersecurity work spans network security, cloud security, risk management and secure-by-design practices.
.png?h=420&iar=0&w=420)
.png?h=420&iar=0&w=420)
