Home / Knowledge Base / Security & Risk Management / What ‘Managed’ Really Covers: A Plain‑English RACI for Hosting, Security and Compliance
  1. Home
  2. »
  3. Knowledge Base
  4. »
  5. Security & Risk Management
  6. »
  7. What ‘Managed’ Really Covers: A…

What ‘Managed’ Really Covers: A Plain‑English RACI for Hosting, Security and Compliance

Table of Contents

What ‘Managed’ Really Covers: A Plain‑English RACI for Hosting, Security and Compliance

Who This Guide Is For (And Why “Managed” Is So Confusing)

Managed hosting sounds reassuring. It suggests someone else is taking care of the messy technical parts so you can focus on your website, your customers and your business.

The problem is that “managed” means very different things from one provider to the next. Unless you are careful, you can end up in a gap where everyone assumes someone else is responsible.

Typical situations where “managed” becomes a problem word

Some common real world examples:

  • The WooCommerce outage: Your “fully managed” WooCommerce site slows to a crawl on Black Friday. The host says “the server is fine, it is your plugin load”. Your developers say “the host should auto scale and tune the database”. Customers just see a broken shop.
  • The security incident: A WordPress plugin vulnerability is exploited. You thought your managed host “handled security”. They tell you they manage the server and firewall, not your plugins or admin accounts.
  • The compliance surprise: A customer or bank asks for PCI documentation. Your provider describes their data centre controls, but your internal processes and application are outside their scope. You discover this when forms need signing, not at the planning stage.

In each case, nobody has been deliberately misleading. The phrase “managed hosting” just hides an important question:

Who exactly does what, when something needs doing?

What this article will give you: a practical RACI, not more jargon

This guide is about making “managed” concrete so you can make better hosting decisions and negotiate clearer contracts.

We will:

  • Explain the RACI model in plain English
  • Apply it to hosting, security, performance and compliance
  • Show how responsibilities change across shared hosting, VPS, managed and unmanaged virtual dedicated servers, and enterprise WordPress setups
  • Give you a simple checklist you can use with any provider, not just G7Cloud

If you want more conceptual background on shared responsibility in hosting, you can read our separate guide What ‘Shared Responsibility’ Really Means in Hosting, which this article builds upon.

First Principles: What RACI Means in Plain English

R, A, C, I explained without consultancy speak

RACI is a simple way to be clear about responsibilities. It is often used in project management, but it works very well for hosting.

  • R = Responsible
    The person or team who actually does the work. For example, logging into a server and applying security patches.
  • A = Accountable
    The person who owns the outcome and answers for it. There should usually be one “A” for a task. For example, the person who signs off that a site meets a certain uptime or compliance requirement.
  • C = Consulted
    People who give input before decisions or actions. For example, your developers might be consulted about how an update could affect your application.
  • I = Informed
    People who are kept up to date, especially when something goes wrong. For example, marketing or customer service during an outage.

You do not need to use the letters in daily conversation. What matters is the thinking behind them.

How RACI applies to hosting, security and compliance

For each area of your hosting, you can ask four questions:

  • Who actually performs this task in practice? (Responsible)
  • Who ultimately owns the outcome if it goes wrong? (Accountable)
  • Who needs to be involved in decisions? (Consulted)
  • Who needs to know what is happening, especially during incidents? (Informed)

Applied to hosting this covers things like:

  • Backups and restores
  • Server and application security
  • Updates and patching
  • Performance and capacity planning
  • Compliance documentation and audits

Why job titles matter less than who actually does the work

It is easy to write “IT” or “Hosting Provider” in a responsibility table. In real incidents, this is often not specific enough.

For example:

  • “Marketing” might own content but have no idea how to log into WordPress safely.
  • “Developers” might understand the code but not the underlying database tuning.
  • “Hosting provider” might manage the operating system but not touch your plugins, themes or user accounts.

When you build a RACI with your host, try to identify:

  • Which tasks the provider handles end to end
  • Which tasks they can help with if asked, and on what terms
  • Where your internal team must be ready to take action

This is less about job titles and more about who has access, skills and time when it matters.

Levels of Management: From Shared Hosting to Fully Managed VDS

A horizontal spectrum illustrating the progression from shared hosting through VPS and VDS to enterprise managed setups, with visual markers for how much the provider manages versus what the customer manages.

Unmanaged, “assisted” and fully managed: a quick comparison

You can think of hosting options along a spectrum:

  • Unmanaged:
    The provider supplies the infrastructure and basic connectivity. You install, configure and maintain everything on top. You are responsible for most tasks, though the provider may step in for hardware and network issues.
  • Assisted or partially managed:
    The provider looks after the core server stack (operating system, control panel, security updates) and sometimes basic monitoring. You manage your application, content and many day to day changes.
  • Fully managed:
    The provider takes on a much larger part of the operational burden. This may include proactive monitoring, performance tuning, patching, incident response and some application level support, within agreed boundaries.

The trade offs are straightforward:

  • More management usually means higher cost but less operational effort for your team.
  • Less management usually means lower cost but more responsibility and in house skills needed.

Where common products sit on the spectrum (shared, VPS, VDS, enterprise WordPress)

Broadly, you will see these products in the market:

  • Shared hosting: Many customers on the same server. Very low cost. Usually partially managed at the server level, but the application is firmly your responsibility.
  • VPS (Virtual Private Server): Your own virtual server on shared hardware. Often sold as unmanaged or lightly assisted. You or your team are responsible for most configuration and maintenance.
  • VDS (Virtual Dedicated Server): Similar to a VPS but with stronger isolation and allocated resources. A managed and unmanaged virtual dedicated servers offering can range from almost bare infrastructure to a fully managed environment.
  • Managed WordPress hosting: The provider handles the WordPress platform, performance features and security hardening for that platform. You manage content, plugins and themes, within their guidelines. See managed WordPress hosting for examples of what is often included.
  • Enterprise WordPress or custom application stacks: Tailored environments with higher service levels, often with documented SLAs and stricter security or compliance requirements. Our own enterprise WordPress hosting with higher SLAs is one example where a detailed RACI becomes essential.

Within each category, different providers draw the lines in different places. Two “managed VPS” products can have very different RACIs.

How WordPress and WooCommerce change the picture

WordPress and WooCommerce are powerful, but they shift more risk to the application layer:

  • Plugins and themes can introduce vulnerabilities
  • Updates can disrupt functionality or performance
  • Heavy WooCommerce catalogues and checkout flows demand careful database and caching strategies

On a managed WordPress platform, your provider may take responsibility for some of this, for example:

  • Core WordPress updates
  • Security hardening and Web Application Firewall rules for common attacks
  • Platform level caching and image optimisation

On a more generic VPS or VDS, these same tasks usually sit with your developers or site managers. The server can be perfectly healthy while your checkout is slow, which is why RACI for application responsibilities matters just as much as the hosting layer.

RACI for Core Hosting Operations: Who Does What Day to Day

A simple matrix style visual showing different responsibility areas (infrastructure, OS, application, data) against two abstract roles (host vs customer), to make the idea of RACI tangible without actual labels.

Server hardware, virtualisation and network

At the bottom of the stack are the physical and virtual building blocks:

  • Rack space, power and cooling in the data centre
  • Physical servers and storage
  • Virtualisation platform
  • Network connectivity and routing

In almost all cases:

  • Your hosting provider is Responsible for keeping this running
  • The provider is also Accountable for meeting their published uptime commitments for this layer
  • You are typically Informed through status pages and incident reports

Even on unmanaged servers, customers rarely have access or responsibility at this depth.

Operating system, control panel and core services (web, PHP, database, email)

This is where the split between unmanaged, assisted and managed becomes clearer.

  • Unmanaged VPS / VDS:
    You are Responsible for installing and updating the OS, web server, PHP, database and mail services. The provider may help if there is a hardware fault or complete outage, but configuration and day to day maintenance sit with you.
  • Assisted / basic managed:
    The provider installs and maintains a standard stack and may apply routine updates. They are Responsible for the base configuration. You are Responsible for application specific changes, such as custom PHP modules or database tuning for your workload.
  • Fully managed VDS or enterprise platform:
    The provider is Responsible for most OS and core service tasks. You are usually Consulted before significant changes that might affect your application. You remain Accountable for your application behaviour and content.

In each case, clarity on who configures and troubleshoots the database, web server and mail is crucial when performance or reliability issues arise.

Uptime monitoring, incident response and communication during outages

Monitoring is another area where assumptions creep in.

  • Infrastructure monitoring:
    Providers usually monitor hardware, virtualisation and basic network availability. They are Responsible for internal alerts and initial response.
  • Server and service monitoring:
    On managed services, your provider may monitor server health, disk space and key services like web and database. On unmanaged services, you often need to set up your own monitoring.
  • Application monitoring:
    Checking that your home page loads, that checkout works or that API responses are within acceptable times is usually your Responsibility, unless you have an enterprise agreement that explicitly includes application level checks.

For communication, ask your provider:

  • What they monitor
  • What triggers an incident
  • How and when you will be Informed
  • Who is Accountable for post incident reviews

Where responsibilities shift on managed WordPress vs a managed VDS

On a managed WordPress hosting platform, the provider builds their stack specifically around WordPress. They may take on Responsibility for:

  • WordPress specific caching and optimisation
  • Core WordPress updates
  • Platform compatible plugin lists

On a managed VDS, the provider manages the operating system and core services, but the Responsibility for your WordPress application typically sits more clearly with you or your developers.

The value of a managed VDS is control and flexibility. The trade off is that you need to be confident your application team can handle configuration and optimisation tasks, or that you can buy that expertise when needed.

RACI for Security: From Firewalls to WordPress Plugins

Perimeter and server level security (firewalls, WAF, bad bot filtering)

Security starts before traffic reaches your site.

  • Network and host firewalls:
    On most managed services, the provider is Responsible for setting up and maintaining basic firewall rules. On unmanaged servers, you or your team must configure and maintain them.
  • Web Application Firewalls (WAF) and bad bot filtering:
    Many providers include a WAF or traffic filtering layer. A service such as the G7 Acceleration Network sits in front of your site, caching static content, optimising images to AVIF and WebP formats and filtering abusive traffic before it ever reaches your application servers.
  • System hardening:
    Securing SSH, disabling unneeded services and enforcing system level security policies may be included on managed services. On unmanaged servers this usually falls to you.

You remain Accountable for the overall security of your application and data, even if your provider is Responsible for large parts of the technical setup.

Application security: WordPress, WooCommerce and third party plugins

The majority of real world incidents on CMS based sites come from the application layer:

  • Out of date plugins or themes
  • Unsafe custom code
  • Weak form validation or missing access checks

In almost all cases:

  • You or your developers are Responsible for selecting, configuring and updating plugins and custom code
  • Your business is Accountable for their behaviour and any resulting data exposure
  • Your host may be Consulted about compatibility and performance, and will usually be Informed if an incident occurs

Even on managed WordPress, hosts rarely guarantee the security of every plugin or theme. Some will maintain an allow list of vetted plugins or block known problematic ones, but that does not remove your duty to review what you install.

User management, passwords and access control

Security also depends on who can log in and what they can do.

  • Hosting control panel logins:
    The provider is Responsible for the platform itself, but you are Responsible for who in your organisation has access, and for removing access when people leave.
  • WordPress, WooCommerce and other admin accounts:
    You are Responsible and Accountable for creating, managing and revoking user accounts and roles.
  • Multi factor authentication (MFA):
    Your host may provide tools to enable MFA. Enforcing its use across your team is typically your Responsibility.

Providers cannot know your staffing changes or internal separations of duty, so they cannot realistically own this on your behalf.

Monitoring, logging and security incident handling

When something suspicious happens, the ability to trace and respond quickly matters.

  • System and web server logs:
    On managed services, providers keep system level logs and may alert on clear intrusion attempts. On unmanaged servers, log collection and analysis are often your Responsibility.
  • Application logs:
    WordPress, WooCommerce and other applications can log errors and events. Turning this on, storing the logs and monitoring for issues usually sits with you or your developers.
  • Incident response:
    The host is typically Responsible for containing infrastructure level incidents. You are Responsible for application changes, content recovery and customer communication. Both sides should be Consulted and Informed during a real event.

For serious incidents, especially where personal data or card details are involved, clarify in advance who leads on customer and regulator communication.

RACI for Updates, Patching and Performance Tuning

OS, PHP and database patching: who presses the button, who tests

Patching is one of the clearest areas to apply RACI thinking.

  • Who presses the button?
    On managed servers, your host is usually Responsible for applying operating system and core software updates. On unmanaged ones, it is you.
  • Who tests?
    Even when the host applies the patch, you are typically Responsible for testing your site or applications. They cannot know every business workflow or plugin combination.
  • Who decides when?
    For urgent security patches, the provider may apply updates quickly to reduce exposure. For major version changes, they may Consult you and schedule maintenance windows.

The risk trade off is simple:

  • Applying patches early reduces exposure time but may carry more compatibility risk.
  • Delaying patches allows more testing time but increases the window in which a known vulnerability could be exploited.

WordPress core, plugin and theme updates

These updates sit directly in your content management process.

  • On generic VPS / VDS setups, you are Responsible for running updates, testing and rolling back if necessary.
  • On managed WordPress hosting, your provider may take Responsibility for core updates and some plugin updates. Even then, you usually remain Accountable for ensuring your functionality still works as expected.
  • Enterprise WordPress offerings may include staging environments and support for supervised updates, where your provider is Consulted and may assist with testing and rollback plans.

No provider can fully guarantee that an update will not break a specific customisation. What they can do is provide safer tools and processes.

Caching, performance features and capacity planning

Performance is often shared between infrastructure and application.

  • Caching layers and CDNs:
    Your host may provide a caching solution or a global network layer. The G7 Acceleration Network, for example, can cache content closer to users, optimise images to smaller modern formats and block abusive traffic before it reaches your servers. The provider is Responsible for operating this layer, while you remain Responsible for how your application uses it.
  • Code and database efficiency:
    Developers are Responsible for writing and optimising queries and templates. The host can provide guidance and tools but cannot redesign your application.
  • Capacity planning:
    You are typically Accountable for forecasting big campaigns, seasonal peaks and new product launches. The provider is Consulted to recommend suitable capacity and scaling strategies.

Where managed services genuinely reduce risk (and what they still cannot guarantee)

Managed services can reduce the likelihood of outages caused by:

  • Untended operating system vulnerabilities
  • Misconfigured core services
  • Slow response to resource saturation, such as disk filling up

What they cannot entirely remove is risk from:

  • Business logic or code errors
  • Third party plugin issues
  • Sudden traffic patterns that far exceed agreed capacity

Understanding this helps you decide whether you need a managed platform, additional developer support, or both.

RACI for Backups, Disaster Recovery and Uptime Targets

Backups vs redundancy: who owns each part

Backups and redundancy solve different problems:

  • Backups let you roll back in time after data loss, hacking or accidental deletion.
  • Redundancy keeps things running during hardware faults or certain kinds of network or data centre issues.

Typical responsibilities:

  • Backups:
    On managed platforms, your host is usually Responsible for platform level backups and restore tooling. You are Accountable for deciding retention, verifying that backups include everything you care about and keeping your own copies if required by policy.
  • Redundancy:
    The provider is Responsible for built in redundancy at infrastructure level, according to your chosen architecture. You are Responsible for deciding which level of redundancy is justified by your business risk and budget.

Restore testing, RPO/RTO and who decides what is “good enough”

Two important concepts:

  • RPO (Recovery Point Objective): How much data you can afford to lose, in time. For example, 15 minutes of orders or a full day.
  • RTO (Recovery Time Objective): How long you can be offline before it causes unacceptable harm.

Your organisation is Accountable for deciding acceptable RPO and RTO. Your provider can:

  • Explain what their standard backups and architectures can realistically deliver
  • Be Responsible for implementing and maintaining those mechanisms
  • Be Consulted when you review RPO/RTO in light of business changes

Testing restores is often overlooked. You or your team should be Responsible for running realistic restore tests, possibly with help from your provider. Our article From Backups to Business Continuity goes into this in more depth.

High availability, failover and realistic uptime guarantees

Marketing language around “five nines” uptime can be misleading without context.

  • Standard hosting with good redundancy may achieve 99.9 percent or better infrastructure uptime in practice, but application issues are outside that figure.
  • High availability architectures use multiple servers and failover strategies to further reduce unplanned downtime, at higher cost and complexity. Our guide High Availability Explained for Small and Mid Sized Businesses discusses these trade offs.

In a RACI sense:

  • The host is usually Accountable for the uptime of the layers they control, according to your SLA.
  • You are Accountable for overall business uptime, which includes your application code, dependencies on external services and your own deployment practices.

RACI for Compliance: PCI, Data Protection and Audit Trails

A layered stack diagram showing infrastructure at the bottom, platform in the middle and business processes at the top, highlighting that PCI and compliance sit across all layers, not just the hosting platform.

What your host can reasonably cover for PCI and similar standards

Compliance frameworks such as PCI DSS, ISO 27001 or GDPR related obligations cover people, processes and technology. Hosting providers can help most with the technology side.

On a PCI conscious hosting platform, your provider can typically be Responsible for:

  • Physical data centre security controls
  • Network segmentation and firewalling of cardholder data environments
  • System hardening and patch management
  • Logging and retention at the infrastructure layer

They may also be Consulted on your PCI scope and documentation, and Informed about your audit timelines, but they cannot certify your organisation on your behalf.

Where your responsibilities start: policies, people and processes

Compliance is not just a hosting feature.

  • You are Responsible and Accountable for staff training, internal policies, access control processes and incident response plans.
  • You are Responsible for how your application handles, transmits or avoids handling cardholder data, for example by using hosted payment pages.
  • You are Accountable for completing self assessment questionnaires and interacting with auditors or banks.

Our article Hosting for Card Payments: What ‘PCI Conscious’ Really Means goes into detail on these shared responsibilities.

Plain English RACI example for a PCI conscious WooCommerce site

Imagine a WooCommerce store using a redirect to a hosted payment page:

  • Hosting provider:
    Responsible for secure server configuration, segmentation, logging, vulnerability management and providing evidence of those controls.
  • Your development team or agency:
    Responsible for configuring WooCommerce and payment plugins to avoid cardholder data being stored or transmitted through your environment unnecessarily.
  • Your business management:
    Accountable for confirming the scope of your PCI obligations, maintaining policies, and signing the relevant SAQ (Self Assessment Questionnaire).

RACI helps you see that “PCI ready hosting” is only one part of your compliance story.

Common Misunderstandings About “Managed” Hosting

“Managed” does not mean someone is watching your site 24/7 in real time

Managed platforms are usually heavily monitored, but this is not the same as a human watching your particular homepage or checkout at all times.

Infrastructure and service monitoring will often catch major failures. Subtle application level issues may not trigger alerts immediately, especially if the server looks healthy.

“Managed” does not mean your plugins or custom code cannot break

Hosts can provide safe defaults, staging environments and guidance, but they cannot fully control what code runs in your application.

Updates may still cause conflicts. New plugins may still introduce performance issues. RACI keeps the lines clear so you know who to call for which type of problem.

“Managed” does not automatically make you compliant

Compliance frameworks explicitly assume shared responsibility. Even if your hosting platform meets or exceeds the technical requirements, your policies, user management and operational practices are still in scope.

A good provider will be open about what they cover and what remains with you, rather than suggesting that a particular product makes you “instantly compliant”.

Red flags in marketing copy and how to question them

Some phrases to explore more deeply:

  • “We take care of everything for you”
    Ask: “Can you show me a responsibility matrix for security, updates, backups and incidents?”
  • “Fully secure”
    Ask: “Which layers do you secure, and what do you expect us to handle?” Security is always about reducing risk, not absolute guarantees.
  • “100% uptime”
    Ask: “What does that figure apply to? Over what period? How do you handle maintenance windows?” The IETF and similar bodies define protocols, not hosting guarantees. Any uptime promise should be tied to specific layers and remedies.
  • “PCI compliant hosting”
    Ask: “What exactly is within your PCI scope and who signs the SAQ?” Use PCI Security Standards Council documentation as a reference point if needed.

Clear answers are a good sign. Vague reassurances are a signal to probe further.

How to Build Your Own RACI With a Prospective Host

Simple worksheet: the 10 areas you should always clarify

When you speak to a provider, you can build a simple RACI table around these areas:

  1. Infrastructure (power, network, hardware, virtualisation)
  2. Operating system and core services
  3. Application platform (WordPress, WooCommerce, custom stack)
  4. Security (firewalls, WAF, malware scanning)
  5. User and access management
  6. Updates and patching
  7. Backups and restore procedures
  8. Monitoring and alerting
  9. Incident response and communication
  10. Compliance and documentation support

For each, ask:

  • Who is Responsible day to day?
  • Who is Accountable for the outcome?
  • Who is Consulted before changes?
  • Who is Informed when something breaks?

Using RACI to choose between shared, managed WordPress and a managed VDS

RACI can guide product choice:

  • If your team is small and non technical, and your site is mostly standard content or simple e commerce, managed WordPress hosting can move many technical Rs to the provider.
  • If you have in house or agency developers and need custom functionality or integrations, a managed and unmanaged virtual dedicated servers setup gives more control. RACI helps decide which parts you want managed and which you keep.
  • If you are handling sensitive data or critical revenue flows, enterprise or PCI conscious platforms shift more operational risk to a provider with the capacity to manage it, but your internal responsibilities remain important.

When it is time to move to enterprise or PCI conscious hosting

Signs that a more specialised platform may be appropriate include:

  • Regulatory or customer demands for formal SLAs and audit trails
  • Revenue levels where prolonged downtime would be financially or reputationally painful
  • Internal teams spending significant time firefighting infrastructure instead of working on product features

At that point, the RACI conversation becomes more detailed, not less. Managed services are a way to redistribute responsibilities sensibly, not to remove them entirely.

Next Steps: Turning “Managed” From a Buzzword Into a Clear Contract

What to document internally before you change hosting

Before you move providers or change architecture, it helps to document:

  • Which parts of your site or application are most critical to revenue or reputation
  • Who in your organisation currently acts as R, A, C and I for key hosting related tasks
  • Your current RPO/RTO expectations, even if they are approximate
  • Any regulatory or contractual uptime and security obligations

This gives you a realistic starting point for conversations with potential hosts.

Questions to send to your current or future provider

You might ask:

  • “Can you show me what is included as ‘managed’ for this product, in terms of security, updates, backups and monitoring?”
  • “In which situations are you Responsible, and in which are we Responsible, during an incident?”
  • “What do you monitor automatically, and what would you expect us to monitor?”
  • “How do you support compliance efforts for PCI or data protection?”

If you would like a second opinion or want to walk through a RACI for your current setup, G7Cloud can help you map out options and decide whether shared, managed WordPress or a managed VDS is the right fit for your risk and budget.

Where to learn more about shared responsibility and hosting models

For further reading in the G7Cloud Knowledge Base:

If you are planning a new project or reviewing an existing one and want to reduce operational risk without overcomplicating your setup, you are welcome to contact G7Cloud to discuss which mix of managed hosting or virtual dedicated servers aligns best with your team and your responsibilities.

Table of Contents

G7 Acceleration Network

The G7 Acceleration Network boosts your website’s speed, security, and performance. With advanced full page caching, dynamic image optimization, and built-in PCI compliance, your site will load faster, handle more traffic, and stay secure. 

WordPress Hosting

Trusted by some of the worlds largest WooCommerce and WordPress sites, there’s a reason thousands of businesses are switching to G7

Related Articles