PS-7: External Personnel Security

PS-7 requires you to define and enforce personnel security requirements for external personnel (contractors, consultants, third-party operators) who can access your systems, facilities, or data, including clear security roles and responsibilities. Operationalize it by baking those requirements into contracts, access processes, onboarding/offboarding, and evidence collection so you can prove external access is authorized, appropriate, and revocable. ¹

Key takeaways:

• PS-7 is a people-and-access control for third parties, not a questionnaire exercise. ¹
• Your “requirements” must be enforceable: contract terms, role definitions, and workflow gates tied to access. ¹
• Audits fail on missing evidence: who approved access, what role they had, and how you removed it. ¹

PS-7: external personnel security requirement is where third-party risk management meets identity, HR, procurement, and the service delivery teams that sponsor external workers. The control is simple on paper: establish personnel security requirements, including security roles and responsibilities for external providers. ¹ In practice, it becomes a repeatable operating model for how external people get access, what they are allowed to do, what they must do to keep access, and how you prove you did all of the above.

For a CCO, GRC lead, or Compliance Officer, the fastest path is to treat PS-7 as an access governance requirement with contractual teeth. You are standardizing expectations for third parties’ staff (and your internal sponsors of those staff), then mapping those expectations into onboarding/offboarding and periodic checks. The outcome you want is defensible control: every external identity with access is tied to a business owner, a defined role, and a current need; and you can show removal when the need ends.

This page gives you requirement-level implementation guidance: who it applies to, what to build, what artifacts to retain, and how to answer exam questions without scrambling.

Regulatory text

Regulatory excerpt (PS-7): “Establish personnel security requirements, including security roles and responsibilities for external providers;” ¹

Operator interpretation: You must define minimum security requirements for external personnel and make them real in operations. “Establish” means the requirements exist in written form, are communicated, are embedded in contracting and access workflows, and are enforced consistently. “Including security roles and responsibilities” means you clarify what external personnel may do (and may not do), who sponsors them internally, who approves access, and who is accountable for monitoring and offboarding. ¹

Plain-English interpretation (what PS-7 is really asking for)

PS-7 expects a controlled relationship between your organization and external people who touch your environment. That includes:

• Role clarity: External personnel have defined functions (e.g., helpdesk analyst, cloud ops engineer, onsite field technician) with least-privilege access aligned to those functions.
• Responsibility clarity: Your internal stakeholders know who approves access, who reviews it, who escorts visitors, and who confirms termination of access.
• Requirements clarity: External personnel are subject to your baseline security rules (acceptable use, confidentiality, reporting lost devices, MFA use, remote access rules, etc.) and your contracts allow enforcement. ¹

Who it applies to

PS-7 applies wherever external personnel can affect confidentiality, integrity, or availability of your systems, facilities, or data, including:

• Contractor-operated IT functions (managed service providers, SOC providers, IT outsourcers).
• Professional services (consultants, auditors with network access, system integrators).
• Facilities and physical access (maintenance, security guards, datacenter hands).
• Product and engineering third parties (developers with repo access, outsourced QA).
• Temporary staffing (temps using internal endpoints and accounts).

Operationally, it applies to teams that create and manage access:

• Procurement / vendor management (contracts, statements of work).
• HR / contingent workforce program (onboarding, badging).
• IT / IAM (accounts, roles, privileged access).
• Security (standards, monitoring expectations, incident reporting).
• Business owners (sponsorship and access justification).

What you actually need to do (step-by-step)

Use this as the minimum build-out to operationalize ps-7: external personnel security requirement.

1) Define scope and trigger conditions

Create a rule that PS-7 requirements apply when a third party’s personnel have any of the following:

• Logical access (accounts, VPN, SSO, API keys, repo access).
• Physical access (facilities, server rooms, badge access).
• Sensitive data access (production data, regulated datasets, key business IP).

Output: A one-page PS-7 standard that states scope, ownership, and the “no access until requirements are met” gate. ¹

2) Establish external personnel security requirements (baseline)

Write requirements that are enforceable and testable. Keep them short and auditable:

• Identification and authentication requirements (named accounts, no shared accounts where feasible, MFA where available).
• Acceptable use and confidentiality obligations (NDA/contractual confidentiality).
• Device and remote access requirements (only approved methods; prohibit personal device use unless explicitly allowed).
• Incident reporting and cooperation requirements (prompt notification to you through defined channels).
• Physical security expectations when onsite (badging, escort rules if applicable).
• Termination requirements (return badges/equipment; revoke access at end of engagement). ¹

Tip: Requirements that cannot be verified in evidence become audit noise. Tie each requirement to an artifact you can collect.

3) Define roles and responsibilities (RACI for external personnel access)

Document a simple RACI that covers:

• Business sponsor (requests access; confirms need; confirms end date).
• System/data owner (approves access level).
• IAM/IT (provisions and deprovisions).
• Security (sets standards; reviews exceptions; monitors privileged access patterns).
• Third party manager (ensures third party provides required attestations and cooperates). ¹

Make one person accountable for external access hygiene in each major function. Ambiguity is the root cause of orphaned accounts.

4) Embed requirements into third-party contracting

Update templates (MSA/SOW/DPA as relevant) so you can enforce the baseline:

• Require the third party to ensure its personnel comply with your security requirements when accessing your environment.
• Require notification of personnel changes (who is assigned/removed).
• Require return/destruction of credentials, badges, and your data at termination.
• Reserve audit/assessment rights appropriate to the relationship. ¹

Practical gating: Procurement should not issue a PO/SOW for scoped access work unless the PS-7 schedule/addendum is attached or referenced.

5) Implement workflow gates for onboarding and access provisioning

Operationalize PS-7 in the ticketing/IAM workflow:

• Access request requires: external person’s legal name, company, engagement owner, start and end date, systems requested, and role requested.
• Approval chain enforced: sponsor + system owner (and security for privileged roles).
• Provision access with least privilege, time-bound where possible, and with a unique identity tied to the person. ¹

6) Manage changes and offboarding as a first-class process

You need a predictable offboarding trigger:

• End of contract or SOW.
• Sponsor indicates resource left the project.
• Third party notifies personnel rotation.
• Inactivity or failed periodic confirmation.

Then execute:

• Disable accounts, revoke tokens/keys, remove group membership, remove VPN, recover badges, and document completion.
• If the third party used your assets, confirm return and wipe where required by your policies.

7) Run periodic access verification focused on external users

Set a review cadence for external identities (separately from internal if that’s easier operationally). Review should verify:

• External account still needed.
• Role still correct.
• Privileged access still justified.
• End dates are current and enforced. ¹

8) Map PS-7 to a control owner and recurring evidence plan

Make PS-7 assessable:

• Name a control owner (often IAM, Security GRC, or Vendor Risk, depending on where external access lives).
• Define the procedure (the steps above, in your words).
• Define evidence you will produce every cycle. ¹

If you use Daydream, treat this as a control “requirement page” with an assigned owner, linked procedures, and evidence tasks so you can produce assessor-ready artifacts without rebuilding the story each audit.

Required evidence and artifacts to retain

Retain evidence that proves requirements exist and operate. Typical artifacts:

• PS-7 standard / policy section covering external personnel security requirements and scope. ¹
• RACI matrix for external personnel access (sponsor, approver, provisioner, security reviewer).
• Contract clauses / addendum that impose your external personnel security requirements on third parties.
• Access request and approval records for a sample of external users (tickets, IAM logs, approval screenshots).
• Access inventory of external accounts (export from IAM/SSO/VPN) with owner and end date.
• Offboarding records showing timely deprovisioning and badge/device return where applicable.
• Periodic access review evidence (review logs, reviewer sign-off, remediation tickets).
• Exception records for any deviations (shared accounts, emergency access), including compensating controls and expiration.

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “How do you define external personnel?” Auditors want a clear scope rule tied to access and data exposure.
2. “Show me roles and responsibilities.” They look for documented accountability, not tribal knowledge. ¹
3. “Prove access is authorized.” They will sample external accounts and ask for approvals and business justification.
4. “Prove access is removed.” Orphaned external accounts are a classic finding.
5. “How do contracts enforce this?” A policy without contractual flow-down is weak for third parties. ¹

Hangups that trigger findings:

• External identities not tagged in IAM, so you cannot reliably inventory them.
• No end dates on access, so offboarding relies on memory.
• Approvals exist but do not match the access actually provisioned (role drift).

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating PS-7 as vendor due diligence only. Fix: tie it to IAM workflows and make external identity a tracked attribute.
• Mistake: relying on shared or generic third-party accounts. Fix: require named accounts by default; document exceptions with expiry and monitoring.
• Mistake: contracts silent on security responsibilities. Fix: add a standard PS-7 schedule/addendum to MSAs/SOWs for any access-bearing work. ¹
• Mistake: no owner for “external access hygiene.” Fix: assign a single accountable owner and publish the RACI.
• Mistake: offboarding starts too late. Fix: drive offboarding from end-date fields and periodic attestations by sponsors.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PS-7, so you should not expect a PS-7-labeled enforcement narrative to guide implementation. Treat PS-7 as an auditability and breach-prevention control: external accounts are a common path to unauthorized access if you cannot prove sponsorship, least privilege, and deprovisioning discipline. ¹

Practical 30/60/90-day execution plan

Use phased execution without pretending the calendar guarantees completion.

First 30 days (Immediate stabilization)

• Publish a PS-7 standard: scope, baseline requirements, and role/responsibility assignments. ¹
• Identify systems with external access (SSO, VPN, ticketing admin, cloud consoles, code repos).
• Produce an initial inventory of external identities and map each to a sponsor.
• Add a required “end date” field to access requests for external personnel.

Days 31–60 (Make it enforceable)

• Update MSA/SOW templates with external personnel security requirements and notification/offboarding obligations. ¹
• Implement workflow gates: approvals required, privileged access triggers security review, and external user tagging in IAM.
• Start periodic access reviews for external identities; remediate orphaned access promptly.

Days 61–90 (Prove it runs)

• Run a second access review cycle and retain evidence.
• Test offboarding with a tabletop: simulate a third-party staff departure and confirm end-to-end revocation.
• Package your assessor-ready evidence set (policy, RACI, contracts, samples of tickets, review logs, offboarding records).
• In Daydream, map PS-7 to a control owner, document the procedure, and schedule recurring evidence tasks so the process survives personnel turnover. ¹

Frequently Asked Questions

Does PS-7 apply to SaaS vendors if no one at the vendor logs into our tenant?

If vendor personnel have no administrative access into your environment and you have no practical way to control their internal staffing, PS-7 is usually operationalized through contract terms and support-access controls. If vendor support can access your tenant, treat those individuals as external personnel for access governance purposes. ¹

What’s the minimum “roles and responsibilities” documentation an auditor will accept?

A simple RACI that names the sponsor, approver, provisioner, security reviewer, and offboarding owner is often sufficient if it matches how tickets and IAM approvals actually work. Keep it tied to your systems of record so you can produce evidence quickly. ¹

Can we meet PS-7 with a third-party security questionnaire?

A questionnaire can support contracting decisions, but PS-7 expects you to establish requirements and responsibilities for external providers and make them operational in access and offboarding. Auditors will still ask for access approvals, inventories, and deprovisioning proof. ¹

How do we handle third-party personnel who need emergency privileged access?

Define an emergency access path with explicit approval, short-lived credentials where possible, and a required after-action review. Document the exception and close it with evidence of access removal. ¹

What evidence should we provide if the third party refuses to share background screening details?

Keep the contract language that sets your requirements and the third party’s attestation that it meets them, plus your internal approvals and access controls. PS-7 focuses on establishing requirements and responsibilities; you can enforce through flow-down terms and access gating. ¹

Who should own PS-7: Vendor Risk, HR, or IAM?

Assign ownership to the function that can enforce the workflow gate for external access, commonly IAM or Security GRC with strong procurement support. Vendor Risk often supports contracting and third-party obligations, but someone must own access evidence end-to-end. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON