<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Audit — Articles | WebPro Company OÜ</title>
    <link>https://webpro.company/blog/tag/audit/</link>
    <atom:link href="https://webpro.company/blog/tag/audit/rss.xml" rel="self" type="application/rss+xml" />
    <description>Drupal audits and technical reviews — assessing risk, code, modules, permissions and testability before major decisions.</description>
    <language>en-US</language>
    <lastBuildDate>Sat, 20 Jun 2026 06:00:00 GMT</lastBuildDate>
    <item>
      <title>Drupal 7 Migration Statistics in 2026: What the Numbers Really Mean</title>
      <link>https://webpro.company/blog/drupal-7-migration-statistics-2026</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-7-migration-statistics-2026</guid>
      <pubDate>Sat, 20 Jun 2026 06:00:00 GMT</pubDate>
      <category>Migration</category>
      <category>Drupal</category>
      <category>Audit</category>
      <category>Security</category>
      <description>A Drupal 7 migration in 2026 should not be treated as a simple technical upgrade. The statistics point to a wider operational risk that requires audit work, budgeting, content migration planning, and editorial interface decisions. Drupal 7 Has Not Disappeared, Even Though Official Support Has Ended Official security and compatibility support for Drupal 7 ended on 5 January 2025. Drupal.org explains on its Drupal 7 End of Life page that Drupal 7 no longer receives regular community security or compatibility updates after that date. In 2026, the question is no longer whether Drupal 7 will reach end of life. It already has. Public usage data still shows that many websites have not yet moved to a newer Drupal version or another platform. According to Drupal.org usage statistics, more than…</description>
    </item>
    <item>
      <title>E-commerce accessibility after the 2025 deadline</title>
      <link>https://webpro.company/blog/e-commerce-accessibility-after-2025-deadline</link>
      <guid isPermaLink="true">https://webpro.company/blog/e-commerce-accessibility-after-2025-deadline</guid>
      <pubDate>Thu, 18 Jun 2026 06:00:00 GMT</pubDate>
      <category>WCAG</category>
      <category>E-commerce</category>
      <category>Audit</category>
      <description>E-commerce accessibility is not only about colour contrast and image alt text. If a user cannot find a product, use the cart, complete payment or recover from a form error, the service is not really usable. From 28 June 2025, accessibility requirements apply to many services in Estonia and across the EU. The Estonian Consumer Protection and Technical Regulatory Authority explains that the requirements come from national legislation implementing the European Accessibility Act. For an online shop, the practical question is simple: can a person complete the service if they do not use a mouse, use a screen reader, zoom the page or make a mistake in a form? Do not test only the homepage Many accessibility checks start with the homepage. In e-commerce, the real risk is usually inside the…</description>
    </item>
    <item>
      <title>How to assess Drupal development quality</title>
      <link>https://webpro.company/blog/drupal-quality-indicators</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-quality-indicators</guid>
      <pubDate>Sat, 06 Jun 2026 06:00:00 GMT</pubDate>
      <category>Audit</category>
      <category>Drupal</category>
      <description>A good Drupal site works. A very good Drupal site still works after the next security update, the next developer and the next three years. Drupal project quality cannot be assessed from the browser. A clean design and fast loading time are visible — code structure, deployment process and technical debt are not. Here are the indicators to ask about and look for. Version control and deployment What should be in place: Code is in Git, changes go through pull requests or at minimum through branches Production is not deployed to directly — there is a separate development and staging environment Deployment is automated or at least documented step by step Red flag: If someone says &quot;we uploaded via FTP&quot; or &quot;we made the change directly in production&quot; — this is never a one-off incident, it is a…</description>
    </item>
    <item>
      <title>Drupal scanner: a public pre-check before maintenance or upgrades</title>
      <link>https://webpro.company/blog/drupal-scanner-public-precheck</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-scanner-public-precheck</guid>
      <pubDate>Sun, 24 May 2026 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Audit</category>
      <category>Security</category>
      <description>The real state of a Drupal website is best checked with access to code, logs, configuration and the database. A public scanner still helps reveal visible warning signs quickly. The WebPro Drupal scanner is a simple public pre-check. You enter a website address, start the scan and get a first view based on information visible from the outside. It does not log in, change the site or require credentials. The result is not an official audit and it does not prove that a site is safe. A lower result means only that public data did not show an obvious high-risk signal. If you do not know when the site was last updated, it should be checked properly. What it checks The scanner looks for signals that are often visible without logging in: public Drupal and PHP traces; Drupal and PHP support…</description>
    </item>
    <item>
      <title>Technical website audit before acquisition or provider change</title>
      <link>https://webpro.company/blog/technical-website-audit-before-acquisition-or-provider-change</link>
      <guid isPermaLink="true">https://webpro.company/blog/technical-website-audit-before-acquisition-or-provider-change</guid>
      <pubDate>Tue, 31 Mar 2026 06:00:00 GMT</pubDate>
      <category>Audit</category>
      <description>A website can look fine from the outside, but takeover often reveals missing documentation, access, backups or dependency control. What to check before takeover A technical audit shows whether a project can be handed over cleanly. For a Drupal site, there is more to review than public HTML. A good starting point is checking dependencies and upgrade path according to Drupal update principles. Check: whether code is in Git and history is understandable; whether Composer dependencies are clean; whether administrator, server and domain access exists; whether backups can be restored; whether custom code is documented; which security or WCAG risks need quick attention. Why an audit saves money If takeover starts without review, the first month often goes into access problems and hidden…</description>
    </item>
    <item>
      <title>Custom module audit before Drupal migration</title>
      <link>https://webpro.company/blog/custom-module-audit-before-drupal-migration</link>
      <guid isPermaLink="true">https://webpro.company/blog/custom-module-audit-before-drupal-migration</guid>
      <pubDate>Tue, 03 Mar 2026 06:00:00 GMT</pubDate>
      <category>Audit</category>
      <category>Migration</category>
      <category>Drupal</category>
      <description>Drupal core has a documented upgrade path. The real project risk often lives in custom modules that have become critical to the business over the years. What to look for in custom code Drupal update documentation describes the general path, but custom modules must be reviewed project by project. An audit should check: whether the module uses deprecated APIs; which hooks and services are critical; whether the data model is documented; whether the module depends on an old contrib module; whether the feature can be replaced by standard Drupal functionality. How this helps estimation When the state of custom code is known, migration becomes a set of decisions: what to port, what to rewrite and what is no longer needed. This reduces the chance that developers discover major risk in the…</description>
    </item>
    <item>
      <title>How to check if a Drupal module is risky</title>
      <link>https://webpro.company/blog/how-to-check-if-a-drupal-module-is-abandoned-or-risky</link>
      <guid isPermaLink="true">https://webpro.company/blog/how-to-check-if-a-drupal-module-is-abandoned-or-risky</guid>
      <pubDate>Tue, 17 Feb 2026 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Audit</category>
      <description>A Drupal module can solve a problem quickly, but the wrong module can later make updates, security patching and migration difficult. What to check before installation A Drupal module page usually shows maintainers, releases, the issue queue and security coverage. Drupal.org module documentation gives background, but the decision depends on the project. Check: when the last stable release was published; whether the module supports your Drupal version; whether the issue queue shows active maintenance; whether the module is covered by Drupal security advisories; how much custom code the module adds to your project. When to choose another route If a module has no maintainer or the upgrade path is unclear, a cheap solution can become expensive later. Sometimes it is better to use another…</description>
    </item>
    <item>
      <title>Drupal audit checklist before development</title>
      <link>https://webpro.company/blog/drupal-audit-checklist-before-development</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-audit-checklist-before-development</guid>
      <pubDate>Tue, 27 Jan 2026 06:00:00 GMT</pubDate>
      <category>Audit</category>
      <category>Drupal</category>
      <description>A Drupal audit is most useful before a major decision: changing providers, planning migration, preparing procurement or building new functionality on an old system. What to check A useful audit is more than looking at the front page. A Drupal site must be reviewed from technical, editorial and business perspectives. The Drupal update documentation gives a baseline, but the real state appears in code and configuration. The checklist should include: Drupal core and module versions; security update and PHP version status; custom modules, theme and integrations; content types, fields, views and unused configuration; forms, permissions, logs and backups; automated tests or a manual release test plan. When to order an audit An audit is especially important when someone gives a price without…</description>
    </item>
    <item>
      <title>How to evaluate whether your Drupal partner is doing good work</title>
      <link>https://webpro.company/blog/evaluating-drupal-development-partner</link>
      <guid isPermaLink="true">https://webpro.company/blog/evaluating-drupal-development-partner</guid>
      <pubDate>Thu, 08 May 2025 06:00:00 GMT</pubDate>
      <category>Audit</category>
      <category>Drupal</category>
      <description>Good Drupal development shows up when something goes wrong — or doesn&apos;t. Here is what to ask and what to look for before you reach that point. Clients of web projects are often in a position where they are paying for work they cannot evaluate themselves. Drupal development is a technical field — how do you know whether your partner is doing good work? Signs of good work Regular security updates without a special request. A good Drupal partner handles security updates as an automated process, not only when the client asks. Ask: &quot;When were security updates last applied? How does that process work?&quot; A test environment before production. Every change should go through a test environment before reaching the live site. If the partner applies changes directly to production, that is a risk.…</description>
    </item>
    <item>
      <title>What to do when the previous developer is gone — taking over a Drupal project</title>
      <link>https://webpro.company/blog/taking-over-drupal-from-previous-developer</link>
      <guid isPermaLink="true">https://webpro.company/blog/taking-over-drupal-from-previous-developer</guid>
      <pubDate>Wed, 19 Jun 2024 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Audit</category>
      <description>A developer handover is a common situation. Here is a practical guide for taking over a Drupal project without losing anything critical. Why this situation is difficult A Drupal project is more than code. It is: Configuration (modules, settings, roles) Database (content, users) Files (images, documents) Hosting (server, domain, SSL, email settings) External services (analytics, payments, CRM integrations) Knowledge (why things were built a certain way, what known issues exist) The previous developer held all of this in their head. Now you have to reconstruct it. First steps Collect all access credentials Gather everything before contact with the previous developer ends: Hosting — where the site lives, SSH/FTP, cPanel/Plesk Domain — registrar, DNS management Drupal admin — administrator…</description>
    </item>
    <item>
      <title>Accessibility audit — what it covers and what you get</title>
      <link>https://webpro.company/blog/accessibility-audit-what-it-covers</link>
      <guid isPermaLink="true">https://webpro.company/blog/accessibility-audit-what-it-covers</guid>
      <pubDate>Tue, 13 Feb 2024 06:00:00 GMT</pubDate>
      <category>WCAG</category>
      <category>Audit</category>
      <description>An accessibility audit is more than looking at a Lighthouse score. Here is what a professional audit covers and what you receive as a result. Why automated testing alone is not enough Automated tools (axe, Lighthouse, WAVE) are fast and useful — but they find only about 30% of accessibility issues. The rest require human judgement: Does alt text describe the image or just say &quot;image&quot;? Does the error message explain what went wrong? Is navigation logical to a screen reader user? Is the focus order sensible? What an accessibility audit covers Automated scan Automated tests (axe-core, Lighthouse) are run across all main pages. This gives a quick overview and a baseline. Keyboard navigation The entire site is tested without a mouse. Checked: Can every interactive element be reached with…</description>
    </item>
  </channel>
</rss>
