Service cyber resilience: preparing for attacks, outages, and supplier failures

Cyber resilience is not just another security tool

When a service goes down after an attack, DNS failure, or supplier problem, teams often discover an uncomfortable truth: they have individual security tools, but no shared operating plan. One person writes in chat, another opens monitoring, someone searches for the person with DNS access, and users are already seeing errors.

Cyber resilience starts at that moment. It is not a replacement for cybersecurity. Cybersecurity reduces the chance of an incident: patched vulnerabilities, strong access controls, filtering of malicious traffic. Cyber resilience answers a different question: what happens if the incident still occurs?

The recent reason to discuss this topic is Cloudflare’s announcement that it joined the UK Cyber Resilience Pledge. The post mentions governance, leadership accountability, supplier risk, DDoS, and threats strengthened by automation. But for a team that operates a web service, the important part is not the name of the initiative. The important part is turning resilience into daily operational practice.

Scenario: the service works, but the weak points are visible

Imagine a small product team. It has a website, an API, a database, a CDN, DNS, an email service, a payment provider, and several administrative accounts. Last week something worrying happened: some users could not access the site, monitoring showed instability, and the team did not immediately understand whether the problem was in the application, DNS, CDN, or an external API.

That is a good moment for a mini-review. You do not need to start with a 40-page document. Start with one day, one board, and one question: what must remain manageable when something goes wrong?

Layer 1: the map of critical dependencies

The first step is to draw the service as a chain of dependencies. Not a conference-quality architecture diagram, but a working map for an incident. What does a user need in order to complete the main action? Which DNS record points to the service? Where does TLS terminate? Which external APIs are required for payment, login, or message delivery? Where are secrets stored? Who can change settings?

For each critical dependency, write down the owner, the way to check its status, and a fallback path. If the owner is one person on vacation, that is already a risk. If supplier status is checked only through rumors in chat, that is also a risk.

Layer 2: access without heroics

During an incident, one of the worst questions is: who has the password? Access should not be convenient for one person; it should be manageable for the team. Check administrative accounts, multi-factor authentication, emergency access, and permissions that still belong to former team members.

A separate check is whether one compromised mailbox could stop the whole service. If one account can change DNS, delete a backup, and disable payments, cyber resilience is weak even if the code is good.

Layer 3: a backup without a restore test is an assumption

Many teams say: we have backups. A resilient team asks a different question: when did we last perform a restore?

A restore test does not have to be dramatic. Use a small data sample or a test environment. Check whether the backup is accessible, whether the steps are clear, how long it takes to return to a working state, and who has the required permissions. Record the real time, not the time you hope for.

This often reveals practical problems: backups are stored in the same account as the primary system; access keys are not easy to find; instructions are outdated; restore requires a person who is not online.

Layer 4: the first 30 minutes of an incident

An incident runbook should be short. Its purpose is to reduce chaos, not describe every possible disaster. For the first version, include these blocks: who coordinates the incident, where the action log is kept, which checks happen first, and who should be involved for DNS, infrastructure, application, data, and user communication.

Add one rule: during an incident, changes are made only with a recorded time, owner, and reason. This helps the team avoid making the situation worse through random action. If the team does not yet know whether the issue is DDoS, a supplier, or a release, the action log quickly becomes more useful than emotion in chat.

Layer 5: suppliers are part of your resilience

A supplier can be technically strong and still create risk for your product. Check which external services are critical, where contracts or support terms are stored, how to get incident status, and whether an alternative operating mode exists.

For example, if the payment provider is unavailable, can the user save the order? If the email service is down, can messages wait in a queue? If the CDN has an outage, does the team know what can be switched safely and what should not be touched?

Anti-patterns to remove

The first anti-pattern: we have a protective layer, so we are protected. One tool does not replace dependency mapping, access management, restore testing, and runbooks.

The second: the incident plan lives in the head of the most experienced person. That is not a plan; it is a hidden dependency.

The third: a backup exists, but nobody has tested restore. On incident day, that can become an expensive illusion.

The fourth: suppliers are treated as someone else’s problem. Users do not care where the chain broke. They see your service.

A one-day mini-review

Before lunch, build the critical dependency map and check access. After lunch, run a small restore test, write the 30-minute incident runbook, and create a decision list. Some actions can be done immediately: remove excessive permissions, add owners, update contacts, and move the runbook from private notes to a shared place.

By the end of the day, the goal is not perfect security. The goal is better control. The team should know what to check, who to involve, which changes not to make in a hurry, and how to return the service to operation.

Sources

• Cloudflare: Cloudflare joins UK Cyber Resilience Pledge — https://blog.cloudflare.com/cloudflare-joins-uk-cyber-resilience-pledge/
• NCSC: 10 Steps to Cyber Security — https://www.ncsc.gov.uk/collection/10-steps
• NIST Cybersecurity Framework — https://www.nist.gov/cyberframework