Security

Drupal security incident plan

When a website has a security concern, the first hours matter. A good plan avoids panic, lost evidence and random fixes.

An incident starts with suspicion

A security incident does not always mean the site has definitely been breached. It may start with a suspicious log entry, an unexpected file, spam, a malware warning or an unknown user account.

The important point is not to act randomly. If the first reaction is to delete files and clear logs, the team may lose the information needed to understand what happened.

Drupal publishes official notices on Drupal Security Advisories. If the issue may be related to Drupal core or a module, those notices should be checked.

First steps

When there is a security concern, the first task is to preserve the situation, not to fix everything immediately.

A practical order:

  • write down who noticed the issue and when;
  • preserve logs;
  • create a backup of the current state;
  • check recent changes in code and content;
  • review administrator accounts;
  • limit administration access if needed;
  • decide whether public access should be temporarily limited.

If the site handles payments, personal data or user accounts, the data protection owner should also be involved. Technical work and legal responsibility are not the same, but they must move together.

What to avoid

The most dangerous approach is to make many small fixes without a plan. Later it becomes unclear whether the issue is gone, whether it returned or whether evidence was accidentally removed.

Avoid:

  • deleting unknown files blindly;
  • updating modules without a backup;
  • changing user accounts without a record;
  • sharing access with many people at once;
  • publishing a public notice before facts are clear.

Fast action is necessary, but it must be controlled.

After the first response

Once the immediate risk is under control, the next task starts: cause and prevention.

The team should answer:

  • where the issue started;
  • whether Drupal, a module or PHP was outdated;
  • whether passwords and permissions were too broad;
  • whether file permissions were correct;
  • whether backups and restore worked;
  • whether the same issue can happen again.

This follow-up is part of good Drupal maintenance. If a site is taken over after a suspicious event, it makes sense to start with a technical audit, not only with the visible bug.

The plan should exist before the incident

A security incident plan does not need to be a long document. It is enough to know:

  • who decides;
  • who has server and code access;
  • where backups are;
  • how logs can be reached;
  • how public access can be limited if needed;
  • when to involve data protection or management.

If these answers exist before the incident, there is less confusion during one. A Drupal site needs security updates, but it also needs a clear response plan.

Kaido Toomingas Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us