How to prepare an NGO website for an EU-standards audit

If an NGO or charitable foundation is running a project funded by a grant, the website isn’t just a communications tool — it can also come under review during the project audit.

Auditors want to see that the site matches the terms of the grant agreement, the stated technical brief, and the requirements around accessibility, data protection, and project communications.

So it’s better to check everything ahead of time rather than scrambling to fix the site right before the report is due.

1. Check the site’s accessibility

The site has to work well not just for the average visitor, but for people with disabilities too. In the EU, this is governed by the EN 301 549 standard, which ties directly into the WCAG guidelines.

During a review, auditors may check:

• whether images have alt text;
• whether text-to-background contrast is sufficient;
• whether the site works without a mouse, using only the keyboard;
• whether it behaves correctly with a screen reader;
• whether the page and heading structure is clear.

What to do: you honestly don’t need any special expertise to check this. Tools like WAVE, Lighthouse, and others don’t require particular skills to use. It’s also worth preparing a separate page or document describing the site’s accessibility, if your specific project requires one.

2. Check personal-data protection

Did you know there’s legal liability for this? Exactly. My condolences to anyone who found their web developer through "a friend of a friend."

Check:

• whether the site runs on HTTPS;
• what personal data the forms collect;
• whether users are told why that data is needed;
• whether the Privacy Policy is up to date;
• which cookies and analytics services are in use;
• whether consent for non-essential cookies and trackers is set up correctly.

The point isn’t just to have a "Privacy Policy" page — it’s to make sure it actually matches how the site really works.

3. Logos and donor acknowledgement

If the site was built or updated as part of an EU-funded project, there may be mandatory requirements for visual identity. I always ask for the documentation, or look it up on the donor’s website myself.

What usually gets checked:

• whether the EU emblem is used correctly;
• whether the required funding statement and content-liability disclaimer are present;
• whether logo size and placement follow the specific grant programme’s rules;
• whether the programme or project name is spelled correctly.

Don’t just grab an EU logo off Google Images and drop it into the footer. Check it against the actual communication requirements of your grant agreement and programme instead. We once had a case where the donor handed us low-quality source files for a logo — we had to redraw it from scratch, even though that wasn’t in the budget.

4. Reconcile the brief against the budget

This is one of the most important parts of the review.

The auditor doesn’t just care whether the site looks nice and works. They can compare what was planned, what was paid for, and what was actually delivered.

For example, the brief called for an interactive map, but the end result is just a page with a PDF on it. Or the budget covers a specific feature that never made it into the final version.

So before the audit, go through the brief point by point and check that everything promised was actually built.

Separately, gather all the paperwork:

• the technical brief;
• the contract with the developer;
• proposals and documents from the contractor-selection process;
• delivery/acceptance certificates;
• bills and invoices;
• proof of payment;
• the final version of the site.

That makes it much easier to explain to the auditor exactly what was done and what the money was spent on.

5. Access, before the review

If the auditor needs to check the site’s stats or technical side, don’t hand over your main admin password.

It’s better to set up separate access with the exact level of permissions needed ahead of time. For analytics, for example, you can grant access to Google Analytics 4 or Google Search Console without handing over the password to your main account.

If the site has restricted sections or personal accounts, prepare a separate test account.

Don’t change the site during the audit

If the site keeps getting updated, the review results can end up different from what was actually handed over to the client. So during a technical audit, it’s best to freeze a working version of the site and avoid making changes unless you absolutely have to.

Pre-audit checklist

1. Accessibility.
2. Personal-data protection.
3. Logos and the grant programme’s communication requirements.
4. Compliance with the technical brief.
5. Actual work delivered matching the budget.
6. Documents and proof of payment.
7. Access to analytics and restricted sections.
8. A frozen final version of the site.

The main idea is simple: for the audit, you need to prepare not just the site itself, but proof that it was built exactly as the project specified, and for the money that was actually budgeted.

Good luck with your audits, everyone! Especially me — we’re the ones on the hook to pay for any fixes out of our own pocket.