A managed cybersecurity RFP your suppliers can answer

Begin with a decision, not a product list

Write a short description of the business problem and the decision you expect the proposal to support. A growing company may need someone to prioritise improvements; an established team may need coverage during additional hours; a business preparing for a customer review may need a defined evidence programme. These outcomes can lead to different combinations of services. Include the people who will use the proposal in the discussion early. A procurement document becomes less useful when technical staff, finance and management each assume it describes a different operational commitment.

Give a proportionate view of the environment

Provide approximate users, locations, cloud platforms, collaboration tools and major dependencies. State the current security support model and the tools you intend to retain. Identify what is unknown rather than filling gaps with guesses. Suppliers can then explain what discovery they need and which estimates remain provisional. An initial RFP does not need passwords, detailed account identifiers or confidential production diagrams. If detailed information becomes necessary, agree confidentiality and a suitable exchange channel before sharing it. A clear high-level picture is usually more useful than a large unstructured data dump.

Separate workstreams and retained responsibilities

Distinguish assessment, implementation, recurring operation, leadership and emergency response. Ask which activities are included in each proposed workstream and where one-time onboarding ends. Record what your own staff or existing suppliers will continue to do. A responsibility matrix should name the approver, delivery owner and verifier for important decisions. This avoids the common gap where both sides assume the other team will deploy a recommendation, review an alert or contact the business owner. Require the provider to explain dependencies on internal capacity before agreeing delivery milestones.

Ask for evidence that supports acceptance

For each workstream, describe the outcome and invite the provider to propose practical acceptance evidence. A configuration project might produce a verified change record and exception list. A monitoring service needs evidence of source coverage and working handoffs. A leadership engagement needs decisions, priorities and accountable owners. Avoid acceptance criteria that can be met by producing documents nobody uses. Include a service review rhythm, a route for resolving disagreements and an exit plan for access, records and ongoing actions. Those details are easier to agree before the service becomes operational.

Compare assumptions as well as prices

Use the same comparison headings for every response: scope, exclusions, delivery model, required access, licences, hours, response targets, included effort and additional charges. Ask suppliers to state unsupported assumptions explicitly. A lower headline price may reflect a smaller service boundary rather than better value. Where technical testing is part of the programme, give it its own authorised scope and verification purpose. For the transition from procurement to delivery, use the managed security onboarding checklist to define access, coverage checks and operational acceptance.

Technical validation can complement a service programme when it has a separate purpose and authorisation. Our related guides explain technical scoping and procurement and the distinction between ordinary testing and statutory TLPT. Use that work to answer a defined assurance question, then assign the resulting actions to the service owners. These publications are part of the same Atlant Security portfolio.

Use a draft that remains yours to review

Use the services RFP builder to record your platforms, current support, desired coverage and constraints. It produces a proposed shortlist with reasons, followed by an optional AI-assisted draft for your review. Unknown facts remain questions for the proposal. You can amend the draft and submit it to our team with your NDA or existing RFP. Do not include passwords, detailed production identifiers or confidential incident evidence. The tool does not activate a service or agree contractual terms.