What PL-1 policy and procedures requires before an assessor arrives
When an assessment, authorization or contract requires NIST SP 800-53 PL-1, the organization must have a written planning policy and the procedures that put it into practice, both disseminated to the people who plan and run systems and both kept current. PL-1 is the governing document for every other control in the Planning family, including the system security and privacy plan under PL-2, so an assessor will read it first. The control asks for two artifacts: a planning policy that sets out the rules, and procedures that explain how staff carry those rules out. Neither document is meant to be a one-time deliverable. Both need a designated owner, a review cycle with a defined frequency, and triggers for an earlier review, such as a significant change to the environment or a finding from a prior assessment. The organization sets the frequency and the triggers in its own text, so the first task is to read the parameter values in the control as your baseline and confirm what your authorizing official has approved.
The planning policy can be set at the organization, mission or business process, or system level, and the choice matters for scope. An organization-level policy sets common rules that every system inherits, while a system-level policy is narrower and suits a single high-impact environment. Whatever level you choose, the policy should address purpose, scope, roles and responsibilities, management commitment, coordination among the parties who plan systems, and compliance. Assessors check that each of these areas appears and that the named roles match people who actually hold those responsibilities. Confirm with your own environment which official signs the policy, who maintains the procedures, and how the document is disseminated to defined roles, because these answers are what an interviewer will test first.
PL-1 is often weak at audit time for a predictable reason: the policy was written once, copied from a template, and never tied to the systems it governs. Common gaps include review dates that have passed, procedures that describe a tool or team that no longer exists, and no record of who received the document. Before the assessment, check that the policy names current owners, that its review dates are recorded and met, and that each revision has a history showing what changed and who approved it. Version control on a self-hosted wiki or documentation platform can supply that history, so the revision trail is produced by the system rather than reconstructed by hand. Ask your assessor early which evidence of dissemination and review they expect to see, because a policy that cannot show its own history will be scored as incomplete even when its content is sound.
Which policies, systems and teams PL-1 reaches
PL-1 looks like one document, but where the planning policy is set decides which systems inherit it, which teams must acknowledge it, and how far the privacy baseline reaches. SP 800-53B allocates PL-1 to the low, moderate and high security baselines and to the privacy baseline, so every in-scope system needs a clear answer to these questions before the policy is drafted.
Choosing the policy level
The planning policy can be set at the organization, mission or business process, or system level. An organization-level policy is written once and inherited broadly, while a system-level policy suits a single high-impact system with unusual planning needs. Record the chosen level in the policy's scope statement, and confirm with your assessor that the level you picked still lets every in-scope system show a documented planning policy and matching procedures. Mixing levels without a map is a common source of gaps.
Mapping which systems inherit
Build a register that links each information system to the planning policy and procedures it inherits, including the impact level from its categorization. Systems that sit outside the policy's scope boundary, such as a legacy platform owned by another business unit, need a documented exception or their own plan. Ask your assessor to walk the register against a sample of systems, since a policy that names no systems is hard to test.
Assigning owners and acknowledgments
The policy must name a designated official who manages it, and the procedures must reach defined roles. Identify the teams that plan, build and run systems, such as security, platform engineering, application owners and privacy staff, and record who must read and acknowledge the policy. Track acknowledgments with dates in your document system so that a reviewer can see who received each version and when.
Covering third parties and contractors
Where a managed service provider, cloud platform or integrator operates part of a system, decide whether they follow your planning policy, theirs, or a contractual equivalent. Write that decision into the procedures and into the contract or service agreement. Assessors commonly ask who performs planning activities for outsourced components, so the answer must match the documented responsibilities.
Applying the privacy baseline
PL-1 also appears in the privacy control baseline, which applies regardless of impact level. For systems that process personally identifiable information, the policy and procedures should reference privacy planning roles, such as a senior agency official for privacy or the privacy office, alongside security roles. Confirm with privacy staff which systems fall under the privacy baseline, because a system can be low impact for security and still carry a full privacy scope.
Checking scope against the catalog
Before finalizing scope, compare the policy's coverage with the related controls the catalog lists for PL-1: PM-9, PS-8, SI-2 and SI-12. Each one touches roles, personnel, flaw remediation or information handling that the planning policy may assume is already defined. Where a related control is owned by another team, document the handoff so the planning policy does not claim responsibilities it does not hold.
How an assessor tests PL-1 under SP 800-53A
SP 800-53A assesses PL-1 through 17 determination statements using the examine and interview methods. The examine method is the document review: the assessor reads the planning policy and the procedures that implement it and checks each determination statement against the text. The assessor is looking for a written policy at the level the organization has chosen, with the required content, a named official, and stated review and update points. Documents that exist but do not say who owns them or when they are reviewed usually fail the examination.
- Purpose, scope and roles: The policy should state why it exists, which systems and organizational units it covers, and who is responsible for each part of planning.
- Management commitment and coordination: Look for a statement of leadership support and a description of how planning coordinates with other control families.
- Compliance mechanism: The policy should explain how compliance is checked, such as by reference to a review process or to the system security and privacy plan.
- Procedures as separate evidence: Procedures should describe steps a practitioner follows, not restate the policy.
- Dates and version history: Confirm the document carries a version, an approval date and a next review date that matches the defined frequency.
Before the assessment, check that every element above is visible in the current version of the document, not only in a draft.
The interview method tests whether the people with planning responsibilities know the policy, follow the procedures and can describe how the policy is disseminated and updated. The assessor selects roles such as the system owner, the information system security officer and the privacy officer, then asks them to explain their part in the process. Answers are compared with the written documents. A gap between what staff say and what the policy says is a common finding even when the document itself is complete.
- Awareness of the policy: Interviewees should know where the current policy is stored and that it applies to them.
- Role clarity: Each interviewee should name the official responsible for the policy and the procedures.
- Dissemination: Staff should be able to describe how the policy reached them, such as through an acknowledgment or a training notice.
- Review trigger: Interviewees should describe the events that prompt an update, such as a significant system change or a new regulatory requirement.
- Consistency with records: Answers should match the dates and approvals in the document history.
Before interviews, brief the named roles on the policy, confirm they can locate it, and prepare a short walkthrough of the last review.
Assessment findings for PL-1 tend to come from documents that are present but incomplete, out of date or disconnected from daily practice. Because the examine and interview methods are paired, a weakness in one often shows up in the other. Findings are recorded in the assessment report, and the organization decides how to address each one through its plan of action and milestones. The points below are patterns to check for, not statistics.
- Undefined review frequency: The policy says it will be reviewed but gives no interval or triggering events.
- No designated official: The document names a team but not an accountable person or role.
- Procedures missing or generic: Procedures are copies of the policy and describe no steps.
- Stale approvals: The last approval predates a major change in the system or the organization.
- Unaligned scope: The policy covers one set of systems while the system security and privacy plans cover another.
Before the assessment, read the policy against each pattern and record the fix, owner and date for any item you find.
Implementing the PL-1 policy and procedures in sequence
This sequence turns PL-1 from a document idea into an approved, disseminated and reviewable planning policy and set of procedures that an assessor can examine and trace to real planning activity. Each step produces an artifact that the next step depends on.
Set the policy level and scope
The organization decides whether the planning policy applies at the organization, mission or business process, or system level, and states which systems, business units and personnel it covers. The security or compliance lead records this decision in a scope statement and confirms it with the owners of the systems in question. The step is complete when the scope statement names the level chosen and lists the systems or processes it governs, so an assessor can see where the policy applies.
Assign a designated official
Management names a designated official who owns the planning policy and procedures, maintains them and answers questions about them. The appointment should be written, approved by a senior owner and recorded in the policy's document control block. The step produces a named role and an appointment record. Confirm that the official has the authority and time to keep the documents current, because an unowned policy is a common finding.
Draft the planning policy
The designated official drafts the policy so it addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities and compliance. Each section should map to a content area the control requires, so the assessor can match the text to the determination statements in SP 800-53A. The output is a draft policy with a clear owner, version number and a short list of the roles it assigns. Legal, privacy and system owners review the draft before it moves forward.
Write the planning procedures
Write procedures that show how people carry out the policy in practice. Procedures name the activities, the roles that perform them, the inputs and outputs, and the records they produce, such as the planning steps that feed the system security and privacy plans and their approval. The output is a procedure document that a practitioner can follow without interpretation. Test each procedure by walking through one real planning cycle with the people who will run it, and correct any step they cannot perform.
Disseminate the policy and procedures to defined roles
Distribute the approved policy and procedures to the roles the policy defines, and record who received them and when. Use the document system's access controls so that the right roles can read and edit the text while others can only read it. The step closes when distribution records exist for each defined role and the designated official can show who has access. Acknowledgment of receipt by key role holders strengthens this evidence.
Set review frequency and event triggers
Define how often the policy and procedures are reviewed and updated, and list the events that force an earlier review, such as a significant system change, a change in the organization's mission, a new regulatory requirement or an assessment finding. The defined frequency and triggers belong in the policy text itself. The output is a review schedule and a trigger list that the designated official tracks. Confirm the chosen interval against your own governance calendar and any parameter values set in your baseline.
Retain approval and review records
Keep a dated record of each approval, each review and each update, including the approver, the changes made and the reason for them. Version control in a wiki or documentation platform can hold this history automatically if it records who changed what and when, and allows comparison between versions. The step is complete when an assessor can pick any version of the policy and trace its approval and its changes. Confirm that your chosen tool retains this history for the full retention period your governance program requires.
Evidence that passes PL-1 and how to keep it current
An assessor testing PL-1 checks that the planning policy and its procedures exist, were approved and disseminated, and are reviewed on schedule. The cards below cover each artifact and how to keep it current between assessments without rewriting documents each cycle.
Approved planning policy
The signed planning policy should state its purpose, scope, roles, responsibilities, management commitment, coordination among entities and compliance expectations, and name the level it applies to: organization, mission or business process, or system. Check that the approval record names the official who accepted it and the date. Keep the policy short and stable, and move system-specific detail into procedures so routine updates do not force a policy revision.
Implementing procedures
Procedures describe how staff carry out the policy: who drafts a system security plan, how reviews are scheduled, and where records are filed. Assessors compare procedures against the policy to confirm they agree on owners and frequencies. Keep procedures in a separate document with its own version number so operational steps can change without reopening the policy approval. Confirm each procedure names a role rather than a person who may leave.
Dissemination records
Evidence that the policy and procedures reached the defined roles is usually a distribution list, an acknowledgment log, or a read-receipt report from the document system. Assessors look for coverage of every role the policy names, not just the authors. Record the date of each distribution and the recipients, and reconcile the list against role changes at least at each review cycle so new staff in planning roles are included.
Version history with review dates
A version history shows each review and update, what changed, when, and by whom. Assessors use it to verify the defined review frequency was met, including reviews with no changes, which should be recorded as reviewed. Keep the history in the document system itself rather than in filenames. Check that gaps between review dates do not exceed the frequency stated in your own policy.
Designated official appointment
PL-1 expects a designated official to manage the policy. The appointment letter or role description should name the position, its authority to update procedures, and its duty to run reviews. Assessors check that the appointment is current after staff changes. Record the appointment in the policy itself and in the access roster for the document system, so the named owner can actually edit and approve changes.
Change log tied to defined events
PL-1 requires updates after defined events, such as a new system authorization, a significant change, an incident, or a shift in the organization's structure. Keep a change log that links each update to the triggering event and its ticket or decision record. Assessors test whether updates followed the events you defined, so a log entry should always name which trigger applied. Review the trigger list yearly against your change management records.
Using wiki and version control to prove review history
Assessors testing PL-1 want to see more than a current planning policy. They want proof that the policy and its procedures were reviewed at the defined frequency, updated after the defined events, and approved by people who had the authority to approve them. A document with no visible history makes it impossible to show that any of that happened, so the organization needs revisions that are dated, attributable and retrievable. Decide before the first assessment which tool will hold the authoritative copy and who may publish changes to it, because the assessor will ask for the same record that the organization uses day to day.
A self-hosted wiki such as XWiki can supply that history directly. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. For PL-1, that means the planning policy and each procedure can carry a traceable chain of revisions, and a reviewer can show the assessor the exact text that was in force on a given date. Confirm with your own deployment that the retained history is not pruned by any retention or purge setting, since a truncated history undermines the review claim.
Role-based permissions in a tool such as BookStack control who may edit and who may only read. BookStack assigns abilities through the roles a user holds and lets administrators override permissions per shelf, book, chapter or page. That allows the policy owner to publish while contributors can propose edits, and it keeps the approval trail separate from the editing trail. The organization still owns the content, the approvers and the approval decisions; the wiki only records them. Name the approving official in the document itself, and confirm with your assessor which approval record, such as a signed memo or ticket, they will accept alongside the wiki history.
What meeting PL-1 costs in money and effort
This table compares the cost components of writing, maintaining and evidencing a planning policy and procedures under PL-1, showing who is paid, whether each cost is one-time or recurring, and what drives it. Use it to see where open-source tooling removes license spend and where staff time remains. No prices or durations are stated because none are published for this control; ask for them in a written quote.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it and what to request in a quote |
|---|---|---|---|
| Drafting the planning policy and procedures | Internal security or compliance staff, plus any consultant drafting support | One-time, then revised | Number of system boundaries and business units in scope. Ask for a fixed deliverable list covering both the policy and the procedures. |
| Legal and security review | Legal counsel and senior security leadership | One-time per major revision | Number of approval rounds and whether the policy must align with other frameworks. Ask who signs off and how many review cycles the quote assumes. |
| Wiki or document tooling | Open-source platform hosting is paid to the infrastructure team; no license fee applies | Recurring hosting and administration | Self-hosted open-source wikis such as XWiki or BookStack remove license spend, but setup, backups and access configuration still need staff time. Ask whether the quote includes hardening and version-control configuration. |
| Periodic review and update | Designated official and control owners | Recurring | The organization sets the review frequency and triggering events. Ask the implementer to size a recurring review cycle and document who performs each step. |
| Dissemination and acknowledgment tracking | Platform administrators and managers of disseminated roles | Recurring | Number of defined roles and user population. Ask how acknowledgments are recorded and retained as evidence. |
| Assessor fees | Independent assessor or auditor, paid directly by the organization | Recurring at each assessment cycle | Scope of the assessment and the assessor's own methodology. Only the independent assessor issues findings, so request a written scope and fee from that firm, not from the implementation partner. |
| Implementation partner preparation | Implementation partner, under a fixed-scope written agreement | One-time for setup, then optional retainer | Number of platforms, roles and evidence sources to prepare. Ask for scope, deliverables and timelines in writing before work starts. |
Who writes, who prepares and who assesses PL-1
The organization owns PL-1. Its leadership must approve the planning policy, and a designated official must be accountable for keeping the policy and its procedures current. The policy has to name the roles that receive it, and the organization decides the review frequency and the events that trigger an update. No outside party can make these decisions on the organization's behalf, and an assessor will look for named people, not a vendor's name, in the approval and ownership records.
- Approval record: a signed or otherwise attributable approval by the accountable executive, with the date and version.
- Designated official: a named role responsible for the policy, its procedures and their upkeep.
- Defined frequency and events: the review interval and triggering events the organization sets for the policy and for the procedures.
- Dissemination list: the defined roles that receive the policy and procedures, and how receipt is recorded.
- Scope decisions: whether the policy applies at organization, mission or business process, or system level, and which systems fall within it.
Before engaging anyone, confirm that an internal owner can answer for each of these items. Ask any partner to show how their draft leaves those decisions open for your executives to make.
An implementation partner can draft the planning policy and procedures, build the place where they live, and set up the systems that keep a change history. The partner works from the organization's existing governance, its mission and its systems inventory. Drafting is effort the organization pays for once, but the content must reflect how the organization actually makes decisions, so the partner needs access to executives and existing documents to do the work properly.
- Draft set: a policy and procedures draft mapped to the PL-1 determination statements, marked as draft until the organization approves it.
- Document hosting: a self-hosted wiki, such as XWiki or BookStack, installed in the organization's own environment.
- Version control: configuration so every change is recorded with the author, date and content, with the ability to compare and roll back versions.
- Access roles: role-based permissions set up so readers, editors and approvers hold only the rights their role requires.
- Evidence capture: a dated record of approvals, reviews and dissemination that the organization can export for assessors.
Ask the partner which parts of the document set they will hand over as files, and confirm that the organization keeps administrative control of the wiki and its backups.
The independent assessor evaluates PL-1 by examining the policy and procedures and by interviewing the people with planning responsibilities. The assessor decides whether the organization meets each determination statement and reports findings. Under the assessment method NIST publishes for SP 800-53, the assessor's conclusions rest on what the documents say, what the staff describe and what the records show. The assessor does not write the policy for the organization, and the assessor cannot both design the control and certify it.
- Examine: the policy, the procedures, approval records, review logs and dissemination records.
- Interview: the designated official and personnel with planning responsibilities, to test whether the documents match practice.
- Findings: a written report of which determination statements are met, partly met or not met.
- Independence limit: an assessor who drafted the policy has a conflict when assessing it, so most organizations keep drafting and assessment with different firms.
- Authority: the organization, or the authorizing official in a federal context, decides what to do with the findings.
When selecting an assessor, ask how they handle a conflict where a sister firm wrote the documents, and confirm who receives the final report.
Most organizations keep policy ownership and approval in-house, and they usually outsource drafting support, wiki setup and evidence capture to an implementation partner. Independent assessment is almost always outsourced to a party that did not write the documents. The split is a matter of cost and skill, not of who is accountable. Costs have several parts: the partner's time for drafting and configuration, the software and hosting the organization runs, the internal time for executive review, and the assessor's fees. None of these figures is set by NIST, and NIST does not estimate compliance costs, so request each item in writing.
- Usually in-house: approval, ownership, scope decisions and the designation of the official.
- Often outsourced: first drafts, wiki installation, version control setup and evidence exports.
- Usually outsourced to an independent party: the examination and interviews that produce findings.
- Recurring work: scheduled reviews, updates after events and keeping dissemination records current.
- One-time work: initial drafting, wiki build and the first approval cycle.
In a quote, ask the partner to separate one-time setup from recurring upkeep, and ask the assessor to state how its fees are structured.
Where PL-1 usually fails at assessment
PL-1 looks simple on paper, yet assessors often find the same few gaps: a policy nobody owns, procedures that describe a different practice, and no proof that people received the documents. Each card below names one gap, what an assessor checks, and the closing action that addresses it.
No designated official owns the policy
The planning policy and procedures must be managed by a designated official, and assessors look for a named person or role in the document itself. A policy signed off by a committee with no single owner usually stalls at review time. Check that the policy names the official, that the role has authority over planning activities, and that the owner's contact is current. Closing action: name one accountable official in the policy header and record the appointment in the approval history.
Procedures that differ from practice
Assessors test the procedures against what teams actually do, so a procedure that describes an annual planning cycle while plans are updated only after audits fails the check. Interview a system owner and compare their steps with the written procedure. Gaps often sit in who drafts plans, who reviews them and where approved plans are stored. Closing action: walk one live system through the procedure and correct every step that does not match what happened.
No evidence of dissemination
Having a policy is not enough: the organization must show that the policy and procedures reached the defined roles. Assessors ask for distribution lists, acknowledgment records or access logs from the document repository. A policy saved to a shared drive with no record of who opened it is hard to defend. Closing action: publish the policy to the defined roles and keep a dated acknowledgment record for each recipient.
Review dates that lapsed
The organization sets review and update frequencies for the policy and procedures, and assessors compare the document's last review date with that schedule. A policy marked for annual review but last approved two years earlier is an easy finding. Check the revision history and confirm each review left a signed record. Closing action: calendar every review date from the approved frequency and assign a named reviewer to each one.
Policy set at the wrong level
PL-1 allows the policy to sit at the organization, mission or business process, or system level, and the choice must fit the scope of the planning work. A single system policy for an enterprise with many systems leaves gaps for shared planning duties, while an enterprise policy with no system-level procedures leaves owners guessing. Confirm that the level matches how plans are actually written and approved. Closing action: document the chosen level and map each planning procedure to it.
No event-driven updates
Beyond scheduled reviews, PL-1 requires updates after defined events, and assessors look for evidence that major changes triggered a review. Examples include a new authorization boundary, a significant incident, or a change in the governing law or the organization's structure. Without a trigger list, updates depend on memory. Closing action: define the triggering events in the procedure and record an update decision after each one occurs.
PL-1 questions buyers ask before hiring help
How much effort does PL-1 take to implement?
The effort depends less on writing the policy than on how many systems, business processes and organizational levels the policy has to cover. PL-1 requires a planning policy and procedures set at the organization, mission or business process, or system level, so an organization with one system and a small governance team has a short list of work, while a federal contractor with several authorization boundaries needs a clear decision on which level each document sits at. Other drivers include how many roles must be named, how many existing policies already touch planning, and how mature the document repository is. Ask any partner to break the effort into drafting, approval, dissemination, and the first review cycle, and to state which of these they will do and which your staff will do.
Can our organization handle PL-1 without outside help?
Yes, many organizations write and maintain PL-1 documents internally, and the control does not require an external party. The questions to answer honestly are whether you have a designated official who will own the policy, whether someone can run the review and update cycle on schedule, and whether your staff can map the policy's content to the assessment procedure in SP 800-53A. Outside help is most useful when the organization has no clear owner, when several overlapping policies need consolidating, or when an assessor is expected to test the documents against a fixed scope. A partner can prepare the policy set and the evidence trail, but the organization approves the policy and owns the control.
How long does PL-1 readiness take?
No duration is supplied for this control, so no timeline should be assumed from this page. The time needed depends on how many policy and procedure documents must be drafted, how many approval layers the organization runs, whether existing policies can be reused, and how quickly stakeholders review drafts. Ask any implementation partner for a written scope that lists the documents in scope, the review rounds included, the staff time expected from your side, and the acceptance criteria for each deliverable. Fixed-scope engagements are typically agreed in writing before work starts, so the timeline should appear in that document rather than in a verbal estimate.
What does PL-1 need from our staff?
PL-1 needs staff who can name the planning policy owner, describe how the policy is disseminated to defined roles, and show who reviews it on the defined schedule. The assessment method for PL-1 includes interviewing personnel with planning responsibilities, so those people must be able to explain the policy in their own words and point to where it is applied. Plan for time from security or compliance leads to draft the content, from system owners to confirm the scope, and from executives to approve it. Staff who will be interviewed should be identified early, because an assessor will test whether the people named in the policy actually know their role.
Can a partner issue the PL-1 assessment or certify our compliance?
No. An implementation partner prepares the policy, procedures, and evidence, but only an independent assessor, auditor or certification body issues assessment results or certifications. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Before engaging anyone, ask who will perform the independent assessment, whether that party is accepted by the authorizing body or contract that requires SP 800-53, and what documents the partner will hand over at the end. Keep the roles separate in the contract so that the organization retains ownership of its control decisions.
How do PL-1 and PL-2 differ, and where does PM-9 fit?
PL-1 is the policy and procedures control for the planning family, while PL-2 requires system security and privacy plans for individual systems. Put simply, PL-1 sets the rules for how planning is done, and PL-2 records the result for a specific system. PM-9 sits in the program management family and concerns risk management strategy at the organization level, and the catalog lists it as a related control for PL-1. Engineers should check that the PL-1 policy references the governance structure that PM-9 defines, so that system plans under PL-2 trace back to one approved policy. Confirm the exact relationships in the catalog and in your own environment before writing them into a policy.
What evidence will an assessor ask for under PL-1?
An assessor will typically examine the planning policy and the procedures that implement it, then check dissemination records, approval history and review dates. The SP 800-53A procedure for PL-1 includes examining the planning policy and procedures and interviewing personnel with planning responsibilities. Keep version history so you can show what changed, when and who approved it. Versioned wikis and document systems can help here, for example XWiki keeps version history and allows comparing and rolling back versions, and BookStack lets administrators control which roles can view or edit each page. Confirm that any tool you choose meets your records requirements before relying on it.
How DeployOpen prepares PL-1 policy and evidence
The sequence turns a planning policy and its procedures into a version-controlled, disseminated and reviewed evidence set that the organization owns and an independent assessor can examine. DeployOpen prepares that set; it does not assess it.
Confirm scope and responsibilities in writing
DeployOpen and the organization agree the systems, business processes and organizational levels the planning policy will cover, along with who owns the policy, who holds the designated official role and which requirements belong to the client. Most engagements are fixed-scope, so the agreed scope, deliverables and timeline are written down before work starts, and the quote follows from that written scope. The step closes when the client signs off a scope statement that names each deliverable.
Inventory existing planning documents
Engineers and the client's policy owner collect every existing planning, security governance and procedure document, including any that cover the same systems under other control families. They note gaps against the PL-1 elements: purpose, scope, roles, responsibilities, management commitment, coordination and compliance. The output is a gap register that lists what exists, where it lives and what is missing, reviewed by the policy owner.
Draft the planning policy with the client
DeployOpen helps the client draft the planning policy at the organization, mission, business process or system level the scope defines. The organization's leadership makes the management commitment and approves the wording, because the policy binds the organization, not the implementation partner. The step closes with a draft that the designated official has reviewed and formally approved, with the approval date and approver recorded.
Write procedures that implement the policy
Working with the teams that perform planning work, DeployOpen drafts the procedures that show how the policy is carried out, such as how plans are drafted, reviewed and approved and how exceptions are handled. Each procedure names the role that performs each step. The procedures are tested by asking the people who will run them to walk through a recent example. The step closes when each procedure has a named owner and a documented walk-through.
Set up self-hosted wiki and version control
Engineers deploy a self-hosted wiki in the client's own infrastructure to hold the policy and procedures. XWiki keeps every page change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack assigns abilities through roles that can be overridden per shelf, book, chapter or page. Access is restricted to the roles the client defines. The step closes when the client confirms the hosting location, backup arrangements and role assignments in writing.
Establish dissemination and review records
DeployOpen configures the wiki so the policy and procedures can be disseminated to the defined roles, with acknowledgments captured where the client requires them. Review and update dates are set according to the frequency and events the client defines, with reminders routed to the designated official. The output is a distribution log and a review calendar. The step closes when a test review cycle has produced a recorded revision and a notification to the designated official.
Compile the PL-1 evidence set
DeployOpen assembles the evidence an assessor would examine: the approved policy, the procedures, version history, dissemination records, review records and the role assignments that show who owns each part. Each item is cross-referenced to the PL-1 determination statements it supports so the client can find it quickly. The evidence set is handed over with an index. The step closes when the client has reviewed the index and confirmed it is complete for the agreed scope.
Hand over to the independent assessor
The client gives the evidence set to its independent assessor or certification body, which decides what it tests and issues any report or certificate. DeployOpen does not issue assessment results, attestations or certifications. The client remains the owner of the controls and answers the assessor's questions. The step closes when the assessor confirms receipt and the client records the open questions for follow-up under the written scope.
