Cyber resilience

How website traffic security supports business resilience

Protect the website functions customers rely on, keep genuine users moving, and make sure someone can respond and restore service when problems occur.

Key takeaways

  • Start with the forms, bookings, or account access your customers depend on.
  • Check that protection reduces abuse while genuine customers can still complete their tasks.
  • Name response owners and test the steps for restoring service.
Illustrative technology planning scene

Start with what customers need to complete

Spam fills the enquiry inbox, making genuine requests harder to find. A new protection rule reduces the noise, but a customer now cannot submit the form. In both situations, the business needs to understand what is failing and who can fix it.

Choose the website functions that matter most, such as making an enquiry, booking an appointment, or signing in. Identify the people and services behind each one, including hosting, forms, email delivery, and support. Protection is useful when it helps keep that complete journey working.

Describe the disruption in business terms

OWASP’s Automated Threats project describes how automated activity can misuse normal website functions. For a business owner, the useful question is what that activity prevents customers or staff from doing.

Record the effect you need to address: spam obscuring real enquiries, repeated requests consuming capacity, suspicious sign-in attempts, or disrupted bookings. Ask the technical team to examine the evidence before choosing a response. A traffic increase can also reflect genuine demand, so volume alone does not explain the problem.

Understand what each protection does

Rate limiting sets a limit on how many requests can be made within a period. Traffic filtering checks incoming requests and may allow, challenge, or block them. OWASP’s denial-of-service guidance considers measures across the application and network, including limiting requests and using external filtering services.

Ask what the proposed measure addresses, how it might affect genuine users, and who will maintain it. Traffic protection works alongside software updates, secure account access, and recovery arrangements. Those responsibilities still need owners after a filtering service is installed.

Agree who notices, decides, and acts

Replace the example roles below with named people or providers, including a backup contact and available support hours. Confirm that each person has the access and authority needed for their part.

Website response responsibilities
ResponsibilityExample ownerWhat to agree
Notice a problemWebsite support leadWho receives alerts, checks failed customer tasks, and assesses urgency.
Approve the responseBusiness service ownerWho authorizes changes and decides when to involve additional help.
Make changesWebsite maintainerWho can adjust rules or settings, record the change, and reverse it if needed.
Contact providersTechnical coordinatorWho contacts hosting, filtering, or form providers and tracks their responses.
Update peopleCustomer service leadWho informs staff and affected customers, through which channel, and when the next update is due.
Confirm recoveryService owner and support leadWho checks the complete customer task and its delivery to the responsible team before closing the issue.

Example: protect an enquiry form without losing enquiries

Imagine a consultation form receiving large amounts of automated spam. The following checks are illustrative, not a claim of a tested InterPro IT Consultants protection result. Agree the test environment and permitted activity with the responsible team and providers.

Before enabling a new rule, record how the form currently behaves. Use clearly labeled test enquiries to check common mobile and desktop browsers, required-field errors, and keyboard access. Confirm that successful submissions reach the intended inbox or customer system and that staff can identify them.

When the rule is introduced, repeat those checks and compare spam, successful delivery, and reports of blocked users. Where the service supports it, reviewing what a proposed rule would block before enforcing it can help identify mistakes. Have an authorized person available to adjust or reverse the change.

After the change, investigate missing enquiries and failed submissions as well as reduced spam. Fewer submissions alone do not show that protection worked. The useful result is less abuse while genuine enquiries still reach the team.

Keep a short record of what was tested

For each significant change, record the environment, date, tester, expected result, actual result, and unresolved issues. Use agreed conditions for tests involving traffic volume or provider failures.

  • Customer task: can intended users complete the journey and receive the expected confirmation?
  • Performance and cost: what extra response delay, often called latency, or operating cost was observed?
  • Response: does an alert reach the responsible person, and can they follow the agreed process?
  • Recovery: can the team carry out a rollback, meaning a return to the previous configuration, or another approved recovery step?

Plan how customers will be served during disruption

Agree how long an important function can be unavailable and what the team can realistically do to restore it. If the enquiry form fails, an approved alternative contact route may help while the underlying problem is fixed. Confirm who keeps that information current and who handles incoming requests.

Different failures need different responses. A bad rule may need reversal; a damaged application may need restoration; a provider outage may need coordinated support. Keep the relevant instructions and contacts accessible, and test recovery in an appropriate environment.

NIST’s Cybersecurity Framework offers a broader structure for managing cybersecurity risk. Our practical application is to review protection, detection, response, and recovery together, with clear ownership and evidence of what has been checked.

Separate planned protection from observed results

Keep three states clear: what is planned, what has been configured, and what has been tested. A diagram or supplier feature list can explain a design, but claims about your service need results from a stated environment and set of conditions.

InterPro IT Consultants’ traffic-protection case combines AWS architecture and configuration with service design and validation planning. Protection levels, response-time targets, and availability assumptions need supporting evidence before they become customer-facing claims.

Review one important website function

Choose one function the business depends on and complete this checklist with the people who run it. Use missing answers to decide the next improvement.

  • Function and impact: what must customers be able to do, and what happens if they cannot?
  • Owner: who is accountable for the complete journey, with a backup when they are unavailable?
  • Warning signs: which alerts, delivery checks, or customer reports indicate a problem, and who reviews them?
  • Support contacts: which website and provider contacts are needed, and what hours do they cover?
  • Recovery steps: where are the approved instructions, who may act, and what alternative service can customers use?
  • Last test: when was the complete journey and relevant recovery process checked, what happened, and which issues remain open?

Keep reading

Why vendor management requires internal technology leadership

Keep business priorities and decisions aligned across suppliers, contracts, and systems.

Read article →

Connect SEO and AI visibility to real customer enquiries

Help visitors understand your services and make contact, then measure the quality of enquiries.

Read article →

Need help applying these ideas?

Bring the technology decision you’re facing. We’ll help clarify your priorities, compare options, and identify a practical next step.

Explore the Technology Health Check