The retailers who came through the last two years of breaches and supply chain failures intact weren't always the biggest or best-funded. They were simply the best prepared internally. That's not a comfortable truth for organisations that have invested heavily in tools and frameworks — but it's the most important lesson the industry has learned.
As the CTO of Appointedd (a SaaS platform serving enterprise retail teams), these shifts aren't distant headlines. They shape every decision we make — from architecture, to incident response, to how we talk about risk with our customers.
We recently wrapped up our ISO 27001:2022 recertification cycle and the thing that stuck with me was that our strongest security control isn't a policy or a tool, but our culture. It's how we work every day.
This is a story about building a system that stays secure because your team believes in it, even when the market around you is chaotic.
Security can't rely on stability anymore
Older frameworks assume a relatively calm world: roadmaps full of certainty, stable teams, predictable release cycles.
Reality now looks very different. Threats evolve constantly. Platforms change weekly. Teams restructure without warning. Attack surfaces grow faster than governance catches up. If your security approach is built for quiet periods, you're already behind.
For retail specifically, the stakes are acute. You're managing customer payment data, loyalty programmes, and high-value trading windows like Black Friday where any disruption costs real money and real trust. A breach is a trading problem, a brand problem, and increasingly a regulatory problem.
And there's a new dimension: AI. Every team adopting AI tooling is introducing new vectors. Data flowing through third-party models, code generated by systems the team didn't write, prompts that might contain sensitive context. The security surface area has grown and changed shape.
A static security framework can't keep pace with that. A security culture can, because culture lives in decisions, not documents. When an engineer instinctively thinks about data flows before using an AI tool, when a PM considers what context they're sharing with an external model, when the team questions whether a new integration meets their security standards, that's culture responding to a novel threat in real time.
What we've learned is that what survives isn't the process. It's the culture.
Agile turned out to be a security asset
We shifted to agile ways of working primarily to improve speed, focus, and delivery. But a surprising outcome emerged: our agile culture made our ISMS stronger.
It starts with visibility. Stand-ups, retrospectives, backlog grooming. These give the team constant opportunities to spot issues long before they become crises. A concern raised in a Tuesday stand-up is a risk managed. The same concern buried in a quarterly review is an incident waiting to happen.
Short cycles also mean smaller windows of exposure. When you deliver often, you don't let vulnerabilities linger. You fix faster and iterate sooner. The gap between "we know about this" and "we've addressed this" shrinks dramatically.
Perhaps most importantly, agile builds shared ownership. Security isn't "someone else's job." It becomes part of everyone's planning, every session, every delivery. When an engineer thinks about data flows before writing a line of code, when a PM considers privacy implications during discovery, when a support team member flags unusual behaviour early, that's security culture at work.
Auditors care about traceability, ownership, and action. Agile builds that naturally, without turning the team into bureaucrats. Every ticket has an owner. Every decision has a trail. Every risk has a path to resolution.
And when things shift (and they always do) rigid structures fall apart. A culture built on agile rhythms holds up. It bends without breaking.
Agile isn't marketed as a security framework. But in practice, it absolutely acts like one.
The supply chain threat is closer than you think
One of the most important shifts we've made is recognising that our security posture isn't just defined by our own code, it's shaped by everything we depend on.
Supply chain attacks are one of the most pressing threats in our space right now. A compromised third-party package or library can introduce malicious code into your application without anyone on your team writing a single bad line. One weak dependency is all it takes.
We've responded by treating our dependency chain as part of our attack surface, not an afterthought. That means scanning our package ecosystems (including npm) to catch vulnerabilities before they reach production. We've introduced deliberate delays on new package access, giving us a window to validate before anything lands in our environment. And endpoint scanning across our dependency chains means we're not just trusting that a package is safe because it was safe last week.
The cultural piece matters here too. When an engineer pauses before pulling in a new library and asks "do we actually need this, and do we trust it?", that’s the same instinct we try to build everywhere else. Dependency hygiene isn't a separate discipline. It's just security thinking applied to a part of the stack that's easy to overlook.
In a world where a single poisoned package can propagate across thousands of downstream systems, that pause is worth a lot.
Incident management reveals what's real
If you want to know how mature your security culture really is, look at how you handle incidents.
The foundation is a no-blame culture. If people fear raising issues, you're already failing. The moment someone hesitates to report a concern because they're worried about blame, your security posture has a hole that no tool can fill. This doesn't mean a lack of accountability, it means accountability without fear, which is how you uncover the truth and prevent recurrence.
Alongside that, every incident is documented, reviewed, and owned. Not glossed over, not minimised, not resolved and forgotten. Actions become backlog items. They're tracked. They close. A lesson identified but not acted on is just dead weight.
The mindset shift is treating incidents not as failures to hide, but as the clearest view you'll ever get of how your system actually works under stress. For retail clients, this matters enormously. When something goes wrong during peak trading, how a vendor responds (how transparent they are, how fast they act, how clearly they communicate) defines the relationship far more than any SLA document.
Culture is invisible until you test it. Then it becomes obvious.
Risk management as part of the rhythm
A static risk register reviewed once a quarter doesn't protect you in a world that changes daily.
Our model is simple: when a risk is identified, it becomes work. Ticket created. Owner assigned. Prioritised alongside features. Tracked until completion.
We don't treat risk management as a side process. It's woven into product and engineering. That means the risks we log get addressed. They don't sit in a backlog "for later."
For enterprise retail clients, this matters. You can't promise resilience tomorrow if you're still reviewing risk today.
The real test
It's easy to look secure when everything is going well. The real measure is what happens when things shift.
We've had a period of significant transition: restructuring, changing priorities, shifting markets. And yet our ISMS didn't falter. It got stronger. Because we didn't rely on rigid structure. We relied on how our teams behave.
Security lived in our actions, our conversations, our decisions. Not just in our policies.
That's what enterprise retail customers deserve from their technology partners: a trusted partner that stays solid through turbulence.
Three principles worth carrying forward
Security is everyone's job. A central team can set standards, but they can't catch everything. When everyone understands that their decisions influence the security posture of the company, the organisation becomes stronger almost by default. High-performing teams have security as part of their muscle memory. They don't wait for policies, they internalise why those policies exist.
Incidents are lessons, not failures. Every incident gives you a clearer view of how your system really works. Handled well, they become the fastest route to improving your platform. Handled poorly, you end up with either blame culture (where people become fearful of reporting) or shallow fixes, where symptoms are patched but causes never addressed.
Risks must translate into backlog items. A risk that isn't connected to real work will almost always be forgotten. The moment you turn a risk into a backlog item, it becomes visible and actionable. Someone owns it. There's acceptance criteria. There's a timeline. This is where agile reinforces ISO beautifully: instead of security and delivery living in two separate worlds, risks slot straight into the engine that actually drives change.
We didn't build ISO to look good. We built a culture to be trustworthy. ISO was the outcome.
In retail, your customers feel your security posture every day, in how the product works, how incidents are communicated, how changes are handled. The organisations that understand that are more secure and more trusted.
And in a market where trust is everything, that difference has never mattered more.
