How to Verify Your Website Security and Respond to Breaches

If you suspect a site has been hacked, preserve the available evidence, restrict risky access, contact your hosting provider or a specialist, then restore a clean backup once you understand the cause of the incident. Do not start deleting files at random; you may lose the logs needed for the investigation or restore the site from an infected backup.

Indicators worth investigating

• Changes to pages or users that the team did not make.
• Unexpected redirects, new files, or warning messages from the browser.
• An unexplained rise in server usage or repeated login attempts.
• Messages sent, or orders or accounts created, that the team does not recognise.
• A sudden failure after an update or after uploading a file from an untrusted source.

A single indicator does not prove a breach on its own, but it is reason enough to gather information and verify methodically.

Quick triage by severity

• High: changes to admin accounts, unknown redirects, or unidentified executable files.
• Medium: repeated error messages, a high volume of login attempts, or changes to a single page.
• Low: an isolated alert that needs checking but does not prove a full incident.
• Every level requires the time, the page and the accounts to be documented before any deletion or restoration.

The initial response, step by step

1. Record what happened: the time, the pages, the messages, the accounts and the changes observed.
2. Preserve the logs and backups: do not overwrite everything before saving what allows analysis.
3. Contain the risk: put the site into maintenance mode or isolate the affected part in coordination with the host.
4. Cut off untrusted access: disable suspect accounts and change the credentials from a trusted device.
5. Identify the entry point: review the updates, the plugins, the permissions, the keys and the server.
6. Restore safely: use a backup known to be clean, then update the components and retest before reopening.

What not to do

• Do not delete files or logs before saving a copy for analysis.
• Do not declare the problem over simply because the page is visible again.
• Do not enter a new password on a device that may not be trustworthy.
• Do not restore an old backup before examining the cause of the incident and updating the vulnerable component.
• Do not conceal the incident from those responsible for the data or for regulatory obligations.

Restoration is not the end of the incident

Once the site is back, monitor the accounts, the logs, the files and the integrations, and verify that the contact details, the payment settings and the forms have not been altered. Record the cause, the action taken, the impact and what must be prevented in future. If personal or financial data is within scope, seek specialist guidance on the appropriate obligations rather than guessing.

When do you need a specialist?

Ask for technical help when you cannot identify the entry point, when the changes recur after restoration, or when the incident extends to email, the domain, the database or multiple servers. Prepare the logs, the timestamps and the list of accounts and updates instead of sharing passwords over an insecure channel.

What should you document after closing the incident?

Record the likely cause, the accounts affected, the files or plugins that were dealt with, the backup that was restored, and what changed in the permissions or the backup policy. This documentation stops the same decision being made again in a later incident.

From response to prevention

Once the incident is closed, carry out a review of permissions, updates, backups, restore testing and monitoring. The guide to ways to protect a website from hacking covers the preventive controls, while this page focuses on verification, response and recovery.

If the site is part of a development or maintenance project with Al Shohab Al Aliyah, use the contact channel to describe the problem and the scope of access. This page claims no security certification and offers no guarantee against being hacked.

Hardening basics that reduce the chance of an incident

• Update the platform, plugins and themes from trusted sources only.

• Enable two-step verification on the admin, hosting and domain accounts.

• Give every user the least permission they need and no more.

• Close unused accounts and keys as soon as they are no longer needed.

Backups and restore testing

Having a backup is not enough on its own; what matters is that it is recent, stored separately, and actually tested by attempting a restore. Many sites discover their backups are unusable at the moment they need them. Decide the backup frequency, the retention period and who has the right to restore before an incident happens, not after.

Personal data and regulatory obligations

If the site collects personal or payment data, dealing with an incident is not confined to the technical side. Review your obligations regarding the protection of user data and notifying the relevant authorities where required, and seek specialist guidance rather than acting on your own judgement whenever individuals' data may have been affected.

Monitor the site continuously, not only during a crisis

Regularly monitoring the logs, login attempts, file changes and security alerts reveals a problem early, before it becomes a full incident. Spotting an unexpected change as it happens shortens the response time considerably and limits the damage.

Security within maintenance at Al Shohab Al Aliyah

Within Website Design & Development and maintenance projects we treat updates, permissions, backups and monitoring as part of normal operation rather than an emergency measure, with access responsibility documented. If an incident occurs on a project of ours, describe the problem and its scope through the contact page without sharing passwords over an insecure channel.

Incident response within Saudi data protection obligations

When a site handles the data of Saudi users, incident response does not end when the page is back online; the Kingdom's Personal Data Protection Law imposes considerations covering data collection, retention and how any potential leak is handled. This regulatory dimension must therefore be part of the response plan, not an afterthought. Within maintenance projects, Al Shohab Al Aliyah treats updates, permissions, backups and monitoring as part of day-to-day operation rather than an emergency measure. Our response methodology follows documented stages: preserving evidence and logs, containing the risk and isolating the affected part, identifying the entry point, then restoring from a backup known to be clean after updating the vulnerable component. The deliverables include documentation of the cause, the accounts affected, the action taken and what must be prevented in future, along with a clear statement of access responsibility. Where individuals' data may have been affected, we recommend seeking specialist guidance on the appropriate obligations rather than acting on individual judgement. We claim no guarantee against being hacked; we build controls that reduce the likelihood and make recovery faster and clearer.