Security Architecture
Company-managed endpoints accessing critical systems meet a security baseline including full-disk encryption, screen lock, endpoint protection, secure configuration, and approved management tooling.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Every company-managed endpoint that reaches critical systems is known, centrally managed, encrypted, locked, protected, updated, and identifiable when it falls out of compliance.
First SOC 2 program
Issue company devices for privileged and customer-data access, enroll them in device management before use, enforce disk encryption, screen lock, operating-system updates, and endpoint protection, and maintain an owner-linked inventory with a documented exception path.
As the company scales
Use zero-touch enrollment, identity-based device compliance for critical access, risk-tiered patch targets, automated quarantine, and fleet reporting that joins device ownership, security state, exceptions, and lifecycle status.
Identify which laptops and workstations may access production, customer data, source code, or administrative systems, and specify required encryption, locking, protection, update, and local-administrator settings.
You should end up with: An endpoint baseline with covered access scenarios and measurable configuration values.
Link each company device to an owner and serial identifier, enroll it in central management, and install endpoint protection before allowing sensitive access.
You should end up with: An owner-linked device inventory with enrollment and protection status.
Configure disk encryption, screen lock, supported operating-system versions, security updates, endpoint protection, tamper resistance, and restricted local administration through management policies.
You should end up with: Applied management profiles and fleet-level compliance results for each required setting.
Investigate devices that stop reporting, disable protection, miss critical updates, lose encryption, or fall outside support; restrict sensitive access until the condition is resolved when risk warrants.
You should end up with: Noncompliance alerts, assigned remediation, and restored-compliance or access-restriction evidence.
Approve time-limited exceptions with compensating safeguards, and lock, recover, wipe, or retire devices when ownership or employment ends.
You should end up with: Expiring exception decisions and device retirement records with final management or wipe status.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The current managed-device population shows actual compliance with assigned lock, update, protection, local-administrator, and management requirements, including noncompliant and stale devices.
Include this context
Device and serial ID
Include this context
Assigned owner
Include this context
Operating system
Include this context
Applied policy
Include this context
Compliance status and reason
Include this context
Last check-in timestamp
Weak evidence to avoid
A dashboard total or one compliant laptop with no complete device population, owners, policy version, failure reasons, or last check-in times.
Confirm what the record proves
The current covered endpoint population has full-disk encryption enabled with identifiable device, protection status, and recovery-key handling.
Include this context
Device and serial ID
Include this context
Assigned owner
Include this context
Encryption status
Include this context
Encryption method
Include this context
Recovery-key status
Include this context
Last reported timestamp
Weak evidence to avoid
A local encryption settings screenshot from one device with no fleet coverage, device identity, owner, recovery status, or central reporting time.
Confirm what the record proves
The approved endpoint standard defines required settings and is implemented through a current assigned management profile, while deviations are separately visible as compliance failures or approved exceptions.
Include this context
Baseline version
Include this context
Required setting values
Include this context
Management profile ID
Include this context
Assigned device scope
Include this context
Approval and effective date
Include this context
Exception reference
Weak evidence to avoid
A security standard alone with no current management profile, device assignment scope, compliance report, effective version, or exception handling.
Type 1
As of the selected date, retain the current approved endpoint standard, its assigned management profiles, the complete current device compliance and encryption exports, and resolved or explicitly approved exceptions.
Type 2
Include every company-managed endpoint authorized for critical access at each required review point, every enrollment and retirement, every period of stale reporting or noncompliance, every material baseline or profile change, and every remediation, quarantine, or approved exception during the review period.
Reconcile active personnel and contractor device assignments, hardware inventory, and identities granted critical access to endpoint-management and protection enrollment; then reconcile baseline requirements to current fleet state and every deviation to remediation or an unexpired exception.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Every company-managed endpoint that reaches critical systems is known, centrally managed, encrypted, locked, protected, updated, and identifiable when it falls out of compliance.
Compare the documented owner with the intended role (Infrastructure / Security Operations / IT), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
Reconcile active personnel and contractor device assignments, hardware inventory, and identities granted critical access to endpoint-management and protection enrollment; then reconcile baseline requirements to current fleet state and every deviation to remediation or an unexpired exception.
As of the selected date, retain the current approved endpoint standard, its assigned management profiles, the complete current device compliance and encryption exports, and resolved or explicitly approved exceptions.
Include every company-managed endpoint authorized for critical access at each required review point, every enrollment and retirement, every period of stale reporting or noncompliance, every material baseline or profile change, and every remediation, quarantine, or approved exception during the review period.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates The current managed-device population shows actual compliance with assigned lock, update, protection, local-administrator, and management requirements, including noncompliant and stale devices.
For each selected record, confirm it demonstrates The current covered endpoint population has full-disk encryption enabled with identifiable device, protection status, and recovery-key handling.
For each selected record, confirm it demonstrates The approved endpoint standard defines required settings and is implemented through a current assigned management profile, while deviations are separately visible as compliance failures or approved exceptions.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.