Chapters: 

Business Objectives using Get Smart Framework

This framework supports:

  • System identification
  • Readiness assessment
  • Risk classification
  • Scan posture decisions
  • Agent posture decisions
  • Exception handling
  • Recommendation generation
  • Managed onboarding
  • Reassessment and expiry rules

 

1. Document Control

Document owner:
Business owner:
Technical owner:
Policy owner:
Version:
Date:
Review cycle:
Approval required from:


2. Purpose

2.1 Purpose Statement

This document defines how infrastructure systems are identified, classified, assessed, and admitted into managed workflows.

The goal is to answer:

What is this system, can we trust it, and how may we interact with it?

2.2 Business Objectives

This framework supports:

  • System identification
  • Readiness assessment
  • Risk classification
  • Scan posture decisions
  • Agent posture decisions
  • Exception handling
  • Recommendation generation
  • Managed onboarding
  • Reassessment and expiry rules

2.3 Scope

This applies to:

  • Servers
  • Workstations
  • Network appliances
  • Vendor appliances
  • Cloud assets
  • OT / ICS systems
  • Medical or regulated systems
  • Field devices
  • Temporary or short-lived systems
  • Legacy or fragile systems

2.4 Out of Scope

This document does not define:

  • Remediation procedures
  • Product implementation details
  • Vendor-specific deployment instructions
  • Production change approval workflows
  • Security incident response procedures

3. Core Vocabulary

Term

Definition

Notes

Machine

A discoverable computing endpoint, device, server, appliance, or controller.

“Box” in plain language.

System

A machine or group of machines providing a business or technical function.

May include dependencies.

Asset

A managed record representing a machine, system, service, or device.

Usually inventory-linked.

Owner

Person or team accountable for the asset.

Business and technical owners may differ.

Requested Role

The intended function of the machine.

Example: web server, HMI, relay, database.

Machine Type

Classification of the machine based on risk, role, and operating context.

Example: legacy server, OT device, vendor appliance.

Evidence

Information used to support a readiness or posture decision.

Scan result, inventory, owner attestation, etc.

Readiness

Degree to which the system is eligible for onboarding or workflow inclusion.

Policy A.

Scan Posture

Whether and how the system may be scanned.

Policy B.

Agent Posture

Whether and how an agent may run on the system.

Policy B.

Exception

A documented deviation from standard policy.

Must have owner, reason, and expiry.

Recommendation

Action or decision produced by the assessment process.

May be technical or governance-related.

Managed Onboarding

Admission into a managed workflow, monitoring process, or operational program.

Requires policy decision.

Trust Status

Current level of confidence in the system’s identity, ownership, and evidence.

May expire.


4. Policy A: Machine Readiness Policy

4.1 Policy Purpose

The Machine Readiness Policy determines whether a system is eligible to be admitted, trusted, assessed, or included in managed workflows.

Plain-language question:

Is this box eligible?

4.2 Readiness Decision Categories

Status

Meaning

Typical Outcome

Approved

Required evidence is sufficient and risk is acceptable.

Admit to managed workflow.

Approved with Limitations

Evidence is sufficient, but restrictions apply.

Admit with conditions.

Review Required

Evidence is incomplete, conflicting, or risky.

Human review needed.

Rejected

System is not eligible under current policy.

Do not onboard.

Exception Required

System violates normal policy but may be allowed under documented exception.

Escalate for approval.

Unknown

Identity, owner, or purpose cannot be confirmed.

Do not trust yet.

4.3 Required Evidence

Evidence Type

Required?

Source

Acceptable Standard

Notes

Asset identifier

Yes

Inventory / discovery

Unique and stable

 

Owner

Yes

CMDB / intake / attestation

Named team or person

 

Requested role

Yes

Intake / owner

Business or technical function stated

 

Machine type

Yes

Classification

Must map to approved taxonomy

 

Network zone

Yes

Diagram / discovery

Known segment or zone

 

OS / platform

Conditional

Scan / inventory

Required where scan allowed

 

Support status

Conditional

Vendor / owner

Required for legacy/vendor systems

 

Criticality

Yes

Owner / business impact

Low / Medium / High / Critical

 

Data sensitivity

Conditional

Owner / security

Required if data is processed or stored

 

Operational constraints

Conditional

Owner / vendor

Required for OT, medical, fragile, or vendor-managed systems

 

4.4 Readiness Rules

Rule ID

Rule

Result

RDY-001

System must have a known owner.

Otherwise Review Required or Rejected.

RDY-002

System must have a declared role.

Otherwise Unknown.

RDY-003

System must map to a known machine type.

Otherwise Review Required.

RDY-004

System must have enough evidence to support trust status.

Otherwise Review Required.

RDY-005

Unsupported or legacy systems require limitation notes.

Approved with Limitations or Exception Required.

RDY-006

Vendor-managed systems require contract or support restriction notes.

Approved with Limitations or Exception Required.

RDY-007

OT / ICS systems require operational impact review.

Review Required by default.

RDY-008

Unknown systems may not be admitted into managed workflows.

Rejected or Unknown.

4.5 Readiness Output

Each readiness assessment must produce:

  • Readiness status
  • Confidence rating
  • Evidence summary
  • Missing evidence
  • Risk notes
  • Recommended next step
  • Exception requirement, if any
  • Reassessment date or expiry

5. Policy B: Scan / Agent Posture Policy

5.1 Policy Purpose

The Scan / Agent Posture Policy determines how a system may be assessed, queried, scanned, or touched.

Plain-language question:

How do we touch this box, if at all?

5.2 Scan Posture Categories

Scan Posture

Meaning

Example

Normal Authenticated Scan

Standard credentialed scan permitted.

Managed IT server.

Controlled Scan

Scan allowed with timing, scope, or rate limits.

DMZ server.

Limited Scan

Only narrow checks allowed.

Fragile or sensitive system.

Passive Observation Only

No active scanning. Use logs, traffic, or inventory.

OT segment.

Manual Evidence Only

No technical scan allowed. Use owner/vendor evidence.

Certified medical appliance.

Prohibited

Scanning not allowed.

Safety-critical or unsupported device.

5.3 Agent Posture Categories

Agent Posture

Meaning

Example

Agent Allowed

Standard agent permitted.

Managed workstation.

Agent Allowed with Controls

Agent permitted with restrictions.

Critical server.

Agent Restricted

Agent generally discouraged or limited.

DMZ or vendor-managed system.

Agent Prohibited

No agent allowed.

PLC, RTU, fragile appliance.

Agent Exception Required

Agent possible only with formal approval.

Legacy production system.

Not Applicable

Agent cannot run due to platform or device type.

Sensor, meter, relay.

5.4 Machine-Type Posture Matrix

Machine Type

Scan Posture

Agent Posture

Default Decision

Notes

Standard IT server

Normal authenticated scan

Agent allowed

Approved if evidence complete

 

Workstation

Normal authenticated scan

Agent allowed

Approved if managed

 

Legacy server

Controlled or limited scan

Restricted or exception required

Review Required

Fragile dependencies.

Vendor appliance

Limited or manual evidence

Restricted or prohibited

Review Required

Contract/support limits.

Medical system

Manual or controlled evidence

Usually prohibited

Exception Required

Certification risk.

OT / ICS system

Passive, limited, or manual

Usually prohibited

Review Required

Uptime/safety risk.

Air-gapped system

Manual evidence

Restricted/prohibited

Review Required

Connectivity constraints.

Cloud instance

Authenticated/cloud metadata

Agent allowed/controlled

Approved if tagged and owned

 

Container workload

Image/runtime scan

Sidecar/agent depends on platform

Review or approved by platform policy

Short-lived assets.

Field device

Limited/manual/passive

Not applicable/prohibited

Review Required

Connectivity/ownership issues.

5.5 Touchability Rules

Rule ID

Rule

Result

TCH-001

If operational impact is unknown, do not actively scan.

Review Required.

TCH-002

If the system is safety-critical, default to passive or manual evidence.

Scan Restricted.

TCH-003

If vendor support forbids changes, do not install agents.

Agent Prohibited or Exception Required.

TCH-004

If the system is fragile, legacy, or undocumented, require human approval.

Review Required.

TCH-005

If the system is short-lived, use platform or image evidence where possible.

Agent may be unnecessary.

TCH-006

If the system is internet-facing, scanning must be controlled and logged.

Controlled Scan.

TCH-007

If the system cannot be uniquely identified, do not apply automated action.

Unknown / Review Required.


6. Reference Architecture: Network Diagram

6.1 Diagram Source

Source:
Date received:
Owner:
Environment represented:
Version / accuracy notes:

6.2 Diagram Purpose

The diagram is used as an environment model to reveal:

  • Network zones
  • Trust boundaries
  • Likely fragile systems
  • Candidate evidence sources
  • Policy differences by zone
  • Areas requiring exceptions or manual review

6.3 Important Rule

The diagram itself is not policy.

It is a reference model used to identify where policies may apply differently.


7. Policy Mapping to Diagram

Example Distribution Environment Reference Architecture

Zone / Area

Typical Systems

Scan Posture

Agent Posture

Policy Notes

Enterprise

IT servers, mail, DNS, jump hosts, workstations

Normal authenticated scan possible

Agent allowed

Standard managed space.

IT DMZ

VPN, web, internet-facing systems

Controlled scanning

Restricted or allowed with controls

Higher caution due to exposure.

OT DMZ

Patch mirror, jump host, WSUS, vault

Limited / controlled

Restricted

Bridge zone.

Supervisory

HMI, historian, app server, SCADA

Cautious, role-based

Restricted

Industrial context.

Local HMI

Workstations, HMI, CCTV, meter, VoIP

Limited

Restricted

Mixed asset types.

Local Station

PLC, RTU, relay, sensor, TAC

Limited / manual

Often prohibited

Fragile or operationally sensitive.

Remote / AMI

Meters, access points, bridges, field devices

Limited / remote constraints

Often prohibited or special

Ownership/connectivity issues.


8. Evidence Sources

8.1 Accepted Evidence Sources

Evidence Source

Used For

Strength

Limitations

Manual intake

Owner, role, purpose

Medium

May be incomplete.

Inventory record

Identity, owner, lifecycle

Medium / High

May be stale.

Provisioning source

Build source, platform, tags

High

Only available for managed assets.

OSQuery or equivalent

Host facts, software, configuration

High

Requires agent/query capability.

Authenticated scan

Vulnerabilities, OS, services

High

May not be safe for all systems.

Cloud metadata

Instance identity, tags, region

High

Cloud-only.

Owner attestation

Business role, restrictions

Medium

Requires trust in owner.

Vendor documentation

Support limits, allowed changes

High

May be generic or outdated.

Vulnerability scan result

Exposure and weakness

High

Depends on scan posture.

Network observation

Presence, traffic, relationships

Medium

Passive and inferential.

Support contract notes

Vendor restrictions

High

Must be maintained.

8.2 Evidence Confidence

Confidence

Meaning

High

Multiple reliable sources agree.

Medium

Evidence is plausible but incomplete.

Low

Evidence is sparse, stale, or indirect.

Unknown

Evidence does not support a decision.


9. Output Model

Each assessment should produce a structured result.

9.1 Required Output Fields

Field

Description

Asset ID

Unique identifier.

System name

Human-readable name.

Owner

Accountable owner.

Requested role

Declared function.

Machine type

Classification.

Network zone

Diagram or discovered location.

Readiness status

Approved, Review Required, Rejected, etc.

Scan posture

Normal, controlled, limited, passive, manual, prohibited.

Agent posture

Allowed, restricted, prohibited, exception required, etc.

Confidence

High, Medium, Low, Unknown.

Findings

Key observations.

Limitations

Known restrictions.

Recommendations

What should happen next.

Exception required

Yes / No.

Expiry / reassessment date

When this decision must be reviewed.

9.2 Example Output Summary

System:
Machine type:
Owner:
Zone:
Readiness status:
Scan posture:
Agent posture:
Confidence:
Recommendation:
Exception required:
Reassess by:


10. Exception Model

10.1 Exception Required When

An exception is required when:

  • Evidence is incomplete but onboarding is requested
  • The system violates normal readiness rules
  • Scanning is normally prohibited but requested
  • Agent installation is normally prohibited but requested
  • Vendor restrictions conflict with operational needs
  • Business criticality overrides normal technical policy
  • Operational safety requires special handling

10.2 Exception Record

Field

Description

Exception ID

Unique identifier.

Asset / system

Affected system.

Policy rule

Rule being excepted.

Reason

Why exception is needed.

Risk

What risk is accepted.

Compensating control

How risk is reduced.

Approver

Accountable approval authority.

Expiry

Date exception ends.

Review cadence

How often exception is reviewed.


11. Test Plan

11.1 Test Plan Purpose

The test plan verifies that the policies produce consistent, explainable, and useful decisions.

The goal is not to test software first.

The goal is to test the decision framework.

11.2 Test Scenarios

Test ID

Scenario

Input

Expected Readiness

Expected Scan Posture

Expected Agent Posture

Pass / Fail

TST-001

Standard managed server

Owner, inventory, OS, zone known

Approved

Normal authenticated

Agent allowed

 

TST-002

Unknown device

No owner, unknown role

Unknown / Review Required

Prohibited

Prohibited

 

TST-003

Legacy production server

Owner known, old OS, fragile dependency

Approved with Limitations / Review Required

Controlled / limited

Restricted

 

TST-004

Vendor appliance

Vendor restrictions documented

Review Required / Exception Required

Manual / limited

Prohibited

 

TST-005

OT PLC

Safety-sensitive field device

Review Required

Manual / passive

Prohibited

 

TST-006

Cloud instance with tags

Owner and metadata known

Approved

Metadata/authenticated

Agent allowed or controlled

 

TST-007

Internet-facing DMZ host

Exposed web system

Approved with Limitations

Controlled

Restricted or controlled

 

TST-008

Short-lived container

Image and platform metadata available

Approved by platform evidence

Image/runtime scan

Platform-dependent

 

12. Test Box Requirements

12.1 Test Box Matrix

Test Box ID

Machine Type

Zone

Owner Known?

Role Known?

Evidence Available

Expected Readiness

Expected Scan Posture

Expected Agent Posture

Notes

BOX-001

Standard IT server

Enterprise

Yes

Yes

Inventory + scan

Approved

Normal authenticated

Allowed

 

BOX-002

Legacy server

Enterprise

Yes

Yes

Inventory + owner notes

Review Required

Controlled

Restricted

 

BOX-003

Vendor appliance

DMZ / OT

Yes

Yes

Vendor docs

Exception Required

Limited/manual

Prohibited

 

BOX-004

PLC / RTU

Local Station

Yes

Yes

Manual + diagram

Review Required

Passive/manual

Prohibited

 

BOX-005

Unknown device

Unknown

No

No

Network observation only

Unknown

Prohibited

Prohibited

 

BOX-006

Cloud VM

Cloud / Enterprise

Yes

Yes

Metadata + tags

Approved

Authenticated/cloud

Allowed/controlled

 

13. Open Questions

Question

Owner

Priority

Due Date

Resolution

Who approves exceptions?

       

What evidence is mandatory for each machine type?

       

Which zones allow authenticated scanning?

       

Which systems prohibit agents by default?

       

How long does readiness status remain valid?

       

What is the minimum output required for onboarding?

       

14. Approval

Role

Name

Approval Date

Notes

Business Owner

     

Technical Owner

     

Security Owner

     

Operations Owner

     

Policy Owner

     

The key distinction is this:

Policy A decides eligibility.
Can this system be admitted, trusted, onboarded, or included?

Policy B decides touchability.
Can we scan it, query it, install anything, or must we keep our grubby little automation paws off it? 🦝

The BRD angle gives you exactly the missing spine: purpose, requirements, evidence, decision rules, outputs, exceptions, and test cases. That keeps the real ideas alive instead of turning them into decorative formatting moss.