Managed security solutions: build the right scope for your business

Start with the outcome you need

Buying managed security solutions should make it easier to answer three questions: what needs protection, who is responsible for protecting it, and what happens when something goes wrong? A long list of tools or an impressive dashboard does not answer those questions on its own.

Our managed security solutions bring platform assessment, improvement planning and clearly scoped support into the same conversation. The right starting point depends on your environment and your team: you may need a focused configuration review, help implementing changes, security leadership, or an agreed monitoring and response model.

Before asking for prices, write down the decision the engagement should support. “We need to reduce unnecessary administrator access and verify the changes” is a more useful brief than “we need better security”. It gives both your team and prospective providers something concrete to scope and accept.

Separate the services before comparing proposals

Use the following distinctions when reviewing a proposal. A provider may combine several workstreams, but each should have its own responsibilities, outputs and limits.

An assessment does not automatically include remediation. Monitoring does not automatically authorise containment. A retainer needs agreed contractual terms before you rely on it. Ask the provider to make those boundaries explicit.

Explore our security assessments, monitoring and SOC operating model, incident response readiness and virtual CISO services to identify the workstreams relevant to your brief.

Scope the environment you actually operate

Start with a short inventory of business platforms and their owners. Include the services that hold sensitive information, control access or support revenue. Record which are operated internally and which depend on an IT provider or other supplier.

• Microsoft 365 and identity: identify tenants, domains, administrator ownership, device management and the business processes relying on email and collaboration.
• Google Workspace: identify your edition, organisational structure, external collaboration, connected applications and administrative arrangements. Our Google Workspace security partner service explains this scope in more detail.
• Cloud infrastructure: identify accounts, subscriptions or projects, production workloads, deployment ownership and existing logging.
• Endpoints and directories: estimate managed and unmanaged devices, operating systems, privileged access and the current EDR or device-management arrangements.
• Business SaaS and development tools: list important accounting, billing, collaboration and code-hosting services, including who approves access and owns each integration.

Approximate numbers are enough for an initial discussion. Unknowns should become discovery questions rather than assumptions hidden inside the price. Do not send passwords, API keys or sensitive exports with the initial enquiry.

Make responsibility visible

A practical service description says who acts, who approves and who is informed. Ask how the provider will work with your existing IT team, managed IT provider, cloud specialists and management.

If your internal team is small, pay particular attention to the work left with you. A technically strong recommendation is difficult to use if nobody has the time, access or authority to implement it.

Example: a mixed SaaS business

Consider a hypothetical business with 180 employees, Microsoft 365, AWS, GitHub and a separate billing platform. An IT provider manages laptops and user onboarding. The business wants better confidence in privileged access and a clearer escalation process.

A useful first engagement could map platform ownership, review selected identity and cloud settings, and produce an agreed improvement register. Implementation support could then address approved changes, with a pilot and verification for each significant adjustment.

Monitoring would be a separate scope decision: which sources are included, what events matter, who reviews them, and what happens outside business hours? If incident-response support is also required, mobilisation and commercial terms need to be agreed. This example illustrates how to build a scope; it is not a client case study or a pre-priced package.

Compare proposals on the same basis

Send each shortlisted provider the same platform inventory, objectives and constraints. Ask for a response that separates initial work, recurring work and optional activities. This makes differences in coverage easier to see.

• Coverage: named environments, assets and exclusions rather than “all systems”.
• Deliverables: the records, changes and reporting you will receive, with clear acceptance criteria.
• Access: required privileges, access approval, confidentiality and handling of your information.
• People and hours: responsibilities, delivery arrangements, coverage hours and escalation routes.
• Dependencies: licences, existing tools, third parties and tasks your team must complete.
• Commercial boundaries: onboarding charges, recurring fees, usage limits and separately billed response or project work.
• Handover: ownership of findings, configuration records and outstanding actions when the service changes or ends.

Avoid comparing only the monthly total. A smaller recurring fee may cover a narrower environment or leave more operational work with your team. Ask providers to explain those differences instead of assuming the packages are equivalent.

Agree how you will know the work is useful

Set acceptance criteria before delivery starts. For a hardening project, this may mean evidence that agreed settings were applied, representative workflows still function and exceptions have owners. For a monitoring engagement, it may mean confirming the agreed sources are connected and exercising an escalation through the named contacts.

For recurring work, choose measures that inform decisions: overdue priority actions, unresolved ownership gaps, the status of agreed coverage, and lessons from exercises or incidents. Reporting should make the next action clear, not simply count activity.

Schedule a review when the business changes. A new cloud environment, acquisition, supplier or customer commitment can change the scope that made sense at the start.

Build a brief before requesting a proposal

You do not need a finished security strategy to begin. Describe your employee count, platforms, current support, desired services and the deadline or business event driving the request. Include any uncertainty you want the provider to resolve.