Services

What it is

A Service is work performed for an organization by people. Services deliver outcomes through effort, expertise, and ongoing execution.

Services may be delivered by internal teams or by third parties. They often rely on tools, but the service itself is the work being done, not the tools used to do it.

A service exists independently of any specific tool or product.

Why services exist

Organizations use services to:

• Access specialized skills or expertise
• Perform work they cannot or do not want to handle internally
• Deliver ongoing operational outcomes
• Scale capacity without adding staff

Services are especially common where work requires judgment, interpretation, or sustained effort over time.

Common examples of services

• Managed security services
• Managed vulnerability scanning
• Penetration testing services
• Incident response services
• Compliance advisory services
• IT operations and support services
• Monitoring and alerting services

Services vs Tools

A service is work performed.
A tool is a product used to perform functions.

Services may use tools as part of delivery, but purchasing a tool does not mean a service is being provided.

For example:

• A vulnerability scanner is a tool
• Managed vulnerability scanning is a service

Services vs Assessments

A service may perform assessments, but a service is broader than any single assessment.

For example:

• A penetration testing service may perform a penetration test assessment
• A managed security service may perform recurring assessments over time

The service describes who is doing the work.
The assessment describes what evaluation was performed.

Services vs Artifacts

Services often produce artifacts, but they are not artifacts themselves.

• The service is the work being performed
• The outputs (reports, tickets, logs, communications) are artifacts

Those artifacts may later be reviewed and accepted as evidence.

How services are represented in FutureFeed

In FutureFeed, services are documented separately from tools, but for convenience they are grouped together with tools in the user interface.

This reflects how organizations typically manage their environments: tools and services are closely related and often bundled together, even though they represent different concepts.

Grouping them simplifies navigation while preserving the distinction between:

• Products (tools)
• Work performed (services)

Common confusion

Because vendors frequently bundle software and services together, services are often discussed as if they are tools. This is common and understandable.

In this documentation model:

• Services are work performed
• Tools are products used
• Assessments evaluate results
• Artifacts record outputs
• Evidence is reviewed and accepted proof

Keeping these roles distinct helps organizations understand responsibility, accountability, and outcomes.

Why this matters

Understanding services as work—not products—helps organizations:

• Clarify who is responsible for outcomes
• Avoid assuming results based on purchases alone
• Track recurring activities over time
• Communicate clearly with stakeholders