Managed Website Hosting for Not-for-Profits in Australia

This page explains what managed website hosting for not-for-profits in Australia actually has to cover: donation form security, appeal traffic peaks, inherited sites with no documentation, shared staff and volunteer logins, patching nobody is funded to do, and backups that have been tested. It is written for charity and NFP digital, marketing and operations leads who carry the website without an internal technical team behind them.

The not-for-profit website risk profile is not the corporate one

A corporate website usually sits inside an organisation that has an IT function, a procurement process and a budget line for infrastructure. A not-for-profit website often does not. It takes money from the public, stores supporter records, issues tax receipts and carries the organisation's reputation, and it is frequently owned by one marketing or communications person who inherited it and who has four other jobs.

That combination produces a specific risk shape. The consequences of an incident are high, because a down or compromised donation page during an appeal costs revenue that cannot be recovered and trust that is hard to rebuild. The capacity to prevent or respond to an incident is low, because nobody is rostered to check whether the CMS has pending security updates or whether last night's backup actually completed.

The standard answer to this is cheap shared hosting plus goodwill. That holds until the first real event: a plugin vulnerability disclosed on a Friday, a card testing attack against the donation form, a PHP version going end of life, or a developer relationship that quietly ended two years ago.

Appeal peaks: EOFY, Christmas and disaster response

Most not-for-profits earn a disproportionate share of their online income in a handful of days. The last week of June, the days before Christmas, Giving Tuesday, and whatever unplanned week a flood, fire or crisis puts the cause on the evening news.

Those peaks behave differently from retail peaks. Retail traffic ramps over hours. Appeal traffic can arrive in minutes from a single broadcast mention or an EDM send to the whole supporter base, hit one URL, and all of it attempts a write operation against the database rather than a cached page read. The usual failure modes are predictable:

• The donation page is excluded from full-page caching for good reasons, so every visitor consumes PHP workers and database connections.
• The EDM platform sends 60,000 emails at once and the opens arrive as a near-instant spike against a server sized for an average Tuesday.
• A third party embed, such as a donation iframe or a video, becomes the slow dependency and blocks rendering while the server itself looks healthy.
• Monitoring checks the home page, which is cached and fine, and never checks the donation form, which is not.

Peak readiness for an NFP is mostly unglamorous preparation: load testing the donation path specifically, confirming PHP worker and database connection limits, putting the appeal landing pages behind a CDN with sensible cache rules, rate limiting the form endpoint rather than the whole site, and having a human on call for the 48 hours either side of 30 June. None of that is exotic. It just has to be somebody's job.

Donation forms, donor data and where it is actually stored

The first question in any not-for-profit hosting audit is where card data touches. If donations are processed by a hosted redirect or a tokenising iframe from Stripe, Braintree or a fundraising platform, card numbers never reach your server and your PCI DSS obligation is the lighter self-assessment path. If the form posts card fields to your own application, even briefly, the obligation is much heavier and almost no NFP is resourced to meet it.

The lighter path is not no obligation. PCI DSS v4.0.1 added requirements that apply directly to the page hosting a payment iframe: you need to manage and justify every script loaded on that page, and detect unauthorised changes to the HTTP headers and script content received by the browser. In practice that means a script inventory, a Content Security Policy that constrains what can execute on the donation page, and change detection so that an injected skimmer is noticed in hours rather than at reconciliation time.

Card testing attacks

Separate from skimming, donation forms are a favourite target for card testing. Attackers push stolen card numbers through a low-value donation form to find which ones still work. The symptoms are a flood of one and two dollar transactions, a sudden spike in declines, gateway fees charged per attempt and chargebacks later. Defences are specific: rate limiting by IP and by fingerprint, a minimum donation amount, bot scoring at the edge, disabling the amount field in the query string, and alerting on decline ratios rather than on transaction counts.

Supporter records

Donor name, email, postal address, donation history and sometimes health or hardship information are all personal information under the Privacy Act. Many charities also sit under additional obligations through funding agreements, state grant conditions or ACNC governance standards. The practical control set is boring and effective: encrypt data in transit and at rest, keep database backups in Australian regions, restrict who can export the supporter list, log that export, and do not keep a decade of form submissions in the CMS because nobody ever wrote a retention rule.

When the last developer has gone

A very common situation: the site was built five or eight years ago by an agency or a contractor who is no longer engaged. There is no repository anybody can find, no documentation, deployment happens by FTP, the staging environment is a folder called /old, and the only person who knew the server password has left.

These sites are not necessarily bad. They are undocumented, which is a different problem. The first work in any engagement like this is discovery: enumerate the hosting account, DNS, registrar, SSL issuance, CMS version, module and plugin inventory with versions, PHP and database versions, cron jobs, outbound email configuration, and every third party service the site calls. Until that inventory exists, nobody can honestly say whether the site is secure, and nobody can quote a restore time. This is the same groundwork that makes a migration to a new vendor possible without a rebuild.

Account security when logins are shared

Not-for-profits run on volunteers, casuals, secondments and board members who need access for one project. Credentials get shared because it is faster, and they are never revoked because nobody owns offboarding.

The fixes are cheap relative to the risk:

• One named account per person, no shared "admin" or "marketing" login, so the audit log means something.
• Multi-factor authentication on the CMS, the hosting control panel, the DNS registrar and the payment gateway, not just the CMS.
• Role separation: content editors do not need the ability to install plugins or edit theme files.
• A quarterly access review that removes accounts for people who left, which for most NFPs is a fifteen minute job once it is scheduled.
• Registrar and DNS held in an organisational account, not in a former staff member's personal email.

Patching a site nobody is funded to look after

Vulnerabilities are published on a schedule that has nothing to do with your funding cycle. A WordPress plugin with a critical authenticated file upload flaw, a Drupal core advisory, an OpenSSL CVE on the operating system, a PHP branch dropping out of security support. The disclosure is public the day it lands, and automated scanning for the vulnerable version follows within hours.

The discipline that works is a triage model rather than a monthly "update everything" ritual. Severity and exploitability decide urgency: a remotely exploitable unauthenticated vulnerability on an internet-facing component gets an emergency patch window, while a low-severity issue in a component you do not use waits for the next scheduled maintenance. That requires someone to be matching published advisories against your actual installed versions, which is the part no volunteer arrangement sustains for long.

Updates also break things, which is the real reason they get skipped. A staging environment and a rollback plan turn patching from a gamble into routine work.

Backups, restores and what ransomware would cost you

Almost every hosting account has backups. Far fewer organisations have ever restored one. The questions that matter are not "do you have backups" but:

• How much data would we lose, measured in hours, if we restored right now?
• How long would the restore take end to end, including DNS and SSL?
• Are the backups stored somewhere an attacker who owns the server cannot reach or delete?
• Do they include the database, the uploaded files, the configuration and the server state, or only the web root?
• When did somebody last complete a test restore into a clean environment?

For a charity mid-appeal, the gap between a four hour recovery and a four day recovery is the difference between an awkward update to supporters and a material revenue loss that has to be explained to the board. Frequent snapshots held off the production host, plus a rehearsed restore, is what turns that from a hope into a number you can state.

Comparison: four ways not-for-profits cover the website

The row that matters most is the fourth column. The reason small organisations end up stuck is that the hosting provider will not touch the application and the web provider has no access to the infrastructure, so every incident starts with a negotiation about whose problem it is. That gap is covered in more detail in web hosting versus managed hosting.

Reporting that satisfies a board and a funding body

Boards do not want a server metrics dashboard. They want to know that a known risk is being managed, and they want evidence they can point to if something goes wrong. Funding bodies and insurers increasingly ask similar questions on renewal: do you patch, do you have MFA, do you test backups, do you have a response plan.

What answers those questions is a dated record. Every vulnerability found and when it was closed. Every update applied and to which version. Every outage, its duration and its cause. Every certificate and domain renewal. Every access change. Kept in order, it becomes the evidence pack for a risk register, a cyber insurance application, a grant acquittal or a website governance and risk review, without anybody reconstructing the year from memory at the last minute.

Frequently Asked Questions

What is managed website hosting for a not-for-profit?

Managed website hosting means the provider is responsible for both the server and the website running on it: operating system and CMS patching, security monitoring, backups, uptime monitoring and incident response, not just keeping the hardware powered on. For a not-for-profit the practical difference is that there is no gap between "the server is fine" and "the donation form is broken". One provider owns the whole path and responds under an agreed service level.

Do not-for-profits need to comply with PCI DSS for online donations?

Yes, if you accept card payments, although the level of obligation depends on how donations are processed. If card fields are hosted by your payment provider through a redirect or tokenising iframe, your scope is the lighter self-assessment path, but PCI DSS v4.0.1 still requires you to manage and monitor the scripts loaded on the donation page. If card details are entered into fields served by your own site, your obligations are considerably heavier and worth redesigning away from.

Our website was built years ago and the developer has gone. Can it still be managed?

In most cases yes. The first step is a discovery audit that documents hosting, DNS, CMS and module versions, PHP and database versions, integrations and credentials, so there is an accurate picture before anything changes. From there the site can be brought under patching, backup and monitoring even without the original build team, and any genuine blockers such as an unsupported CMS major version are identified with a cost rather than discovered during an outage.

How do we handle traffic spikes during an EOFY or disaster appeal?

Plan for the donation path specifically, because that is the part that cannot be cached and the part that earns the money. Load test the actual donation flow before the appeal, confirm PHP worker and database connection limits, serve appeal landing pages through a CDN, apply rate limiting at the form endpoint rather than site-wide, and make sure monitoring checks the donation page and not only the home page. Arrange human coverage for the peak window rather than relying on alerts alone.

Is cheap or free hosting ever acceptable for a charity website?

It can be adequate for a brochure site with no forms, no logins and no payments. Once the site takes donations or stores supporter records, the cost of an incident is far larger than the saving, and low-cost plans typically exclude exactly the work that prevents incidents: CMS and plugin patching, tested restores, security monitoring and after-hours response. The sensible test is to ask what your recovery time would be if the site were compromised tomorrow.

Can we keep our existing hosting and just get the management?

Yes. A management-only arrangement is common where an organisation has donated or discounted infrastructure, a cloud credit program, or hosting mandated by a parent body. The provider takes responsibility for patching, monitoring, backups and incident response on infrastructure you continue to own, provided they are given the access and change control needed to do the job properly.

Working with UnDigital on not-for-profit website hosting

UnDigital looks after websites for organisations where the site carries real consequences, including government, property, corporate and purpose-driven clients, and the engineering team that runs the infrastructure is the same team that writes the application code. That matters for not-for-profits because the most common failure is not a technical one. It is the handoff between a host who will not touch the site and a developer who cannot touch the server.

Engagements start with an audit of what you currently have: hosting, DNS, CMS and plugin versions, donation flow, backup state, access list and monitoring coverage. From there the arrangement is scoped as full managed hosting, or as management only if you already have infrastructure you want to keep, with security monitoring and patching included either way. Pricing is scoped per site rather than published, because a two-page brochure site and a Salesforce-integrated donation platform are not the same job.