SI-1 Policy and procedures: requirements and evidence

What SI-1 policy and procedures requires and why assessors start here

If an assessment is coming and your system and information integrity policy is missing or out of date, SI-1 is the control to fix first. SI-1 asks for a documented system and information integrity policy at the organization, mission or business process, or system level, with implementing procedures. The policy must name a designated official, be disseminated to defined roles, and be reviewed and updated at a frequency and after events that the organization itself defines. Those organization-defined parameters are where the work sits: SI-1 carries 9 of them in Release 5.2.0, so the policy is only as good as the choices you make for who approves it, how often it is reviewed and which events trigger an update.

SI-1 is short, but assessors start here because every other SI control depends on it. Flaw remediation under SI-2, malicious code protection under SI-3, system monitoring under SI-4 and integrity verification under SI-7 all need an owner, a defined scope and a procedure that people follow. An assessor who finds no governing policy will question each of those controls before looking at their evidence. NIST's Release 5.2.0 of 27 August 2025 was issued in response to Executive Order 14306 and updated the -1 controls across the catalog, including SI-1, so a policy written before that release should be checked against the current parameters and discussions. Confirm the current release against the NIST SP 800-53 publication page before you sign off on the revision history.

The usual difficulty is that policies describe intent rather than routines. A policy that says vulnerabilities are patched promptly does not show which systems are in scope, who approves a patch, what the remediation timeframe is, or where the record of the patch lives. The same gap appears for malware protection and monitoring. Before drafting, list the actual patching, malware and monitoring routines your teams run, name the tool and the owner for each, and confirm the procedure matches what happens in practice. Assessors will test the procedure against your records, so every statement in the policy should point to a routine someone can demonstrate.

Which systems, teams and parties SI-1 covers

SI-1 is written once but applies at different levels depending on how the organization is structured and which systems it runs. The cards below cover the decisions that set the size of the work: the level the policy sits at, the baseline each system falls under, the FedRAMP class, and the outside parties whose procedures must match the policy.

Policy level: organization, process or system

SI-1 lets the organization write the policy at organization, mission or business process, or system level. A single enterprise policy with system-level procedures usually keeps patching, malware and monitoring rules consistent, while a system-level policy suits a single authorized boundary. Decide the level before drafting, and confirm that every SI family procedure points to the policy that owns it.

Baseline selection under SP 800-53B

SP 800-53B assigns SI-1 to the low, moderate and high baselines and to the privacy baseline. The baseline a system falls under follows its impact level, so a system categorized as high carries the same policy obligation as a low system but faces a larger set of related SI controls. Record the categorization and baseline in the system security plan so the scope of SI-1 is traceable.

FedRAMP Rev5 Classes B, C and D

FedRAMP's Rev5 baselines require SI-1 at Classes B, C and D. Cloud providers seeking authorization at these classes must have a documented policy and procedures for the SI family, reviewed on the defined schedule. Ask the assessor which class applies, because the policy scope and review evidence assessed for each class can differ in practice.

Patching and update providers

Third parties that deliver operating system patches, container images or vendor updates act on systems the organization owns. Their change procedures must match the SI policy's flaw remediation timeframes, testing steps and approval roles. Confirm in contracts which party tests patches, which party installs them, and where the records of each step are kept.

Monitoring and malware service providers

Managed detection, endpoint protection and log monitoring providers operate sensors and alert queues on the organization's behalf. Their alert triage, escalation and update procedures have to align with the SI policy's monitoring objectives and response roles. Confirm who may change detection rules, who receives alerts, and how the provider's procedures are reviewed when the policy changes.

Privacy baseline and PII processing teams

The privacy baseline applies SI-1 to systems that process personally identifiable information, regardless of impact level. Teams that handle data quality, retention and de-identification need procedures that the SI policy governs, even when those teams sit outside IT security. Name an accountable owner for those procedures and include them in the policy's distribution list.

How SI-1 governs patching, malware protection, monitoring and integrity

SI-1 does not require a scan, a patch or a sensor. It requires a documented system and information integrity policy, implementing procedures, a designated official who manages them, and a defined review cycle. Its value is that one governing document sets the rules the other SI controls depend on. For a CISO, the practical question is whether that document gives each SI control an owner, a timeframe, an exception path and a place in the runbooks engineers actually follow. Assessors test SI-1 by reading the policy and procedures and interviewing the people named in them, so gaps show up as missing owners, undefined parameters or procedures that no one has heard of.

Write the policy so each SI control has a line item that answers four questions: who owns the control, how quickly actions must happen, who can approve a deviation and how that deviation expires. For SI-2 flaw remediation, that means the patch timeframes and the approver for a delayed patch. For SI-3 malicious code protection, it means update cadence and false positive handling. For SI-4 system monitoring, SI-5 alerts, SI-6 function verification, SI-7 integrity and SI-10 input validation, the same four questions apply. SI-1 also has nine organization-defined parameters in Release 5.2.0, so the policy must fill in the values it assigns, such as review frequency and the events that trigger an unscheduled review. Confirm these values against your own baseline and the current NIST release before an assessment.

Procedures are where the policy becomes work. Each procedure should be a runbook that names the tool, the console or command, the record it produces and the person who signs off. An illustrative example: a procedure for SI-2 might require that critical patches are tested in a staging environment, deployed through the configuration pipeline and logged in the change record, with the exception form linked from the policy. The policy should also reference the related controls the catalog lists for SI-1 (PM-9, PS-8, SA-8 and SI-12) so readers know where governance, personnel sanctions, security engineering and information retention connect. If you also run NIST SP 800-171 Rev. 3, requirement 03.15.01 (Policy and Procedures) is derived from SI-1, so one document can serve both frameworks once the mapping is confirmed by your assessor.

How an assessor tests SI-1 and what evidence they request

This table sets out how an assessor works through SI-1 under SP 800-53A, which evidence they ask for, and the findings that appear most often when policy and practice do not match. Read it as a preparation checklist: each row names a test focus and what a reader should have ready before the assessor arrives.

Test focus	What the assessor checks	Evidence requested and common findings
Policy content and scope	Whether a documented system and information integrity policy exists at the level the organization chose and covers the SI family and its scope of systems.	Signed policy with scope statement. Finding: policy names no owner or omits systems in scope.
Designated official	Whether a named official manages the policy and procedures and has authority to enforce them.	Appointment or role description. Finding: the owner named in the policy has left the organization.
Procedures	Whether implementing procedures exist for patching, malware protection, monitoring and integrity controls, and whether they are specific enough to follow.	Procedure documents linked to SI-2, SI-3, SI-4 and SI-7. Finding: procedures describe tools or teams that no longer exist.
Review and update cadence	Whether the organization reviewed and updated the policy at its defined frequency and after defined events.	Revision history and approval records. Finding: a review date has passed with no recorded review.
Dissemination	Whether the policy and procedures reached the defined roles and whether those roles acknowledged them.	Distribution list, acknowledgment records or wiki access logs. Finding: dissemination records are missing for some defined roles.
Consistency with practice	Whether daily operations match what the procedures say, such as patch timeframes and alert handling.	Sample patch tickets, scanner configurations and alert tickets compared with the written procedure. Finding: procedures contradict actual practice.
Staff interviews	Whether the policy owner, system administrators and security staff can describe the policy and where to find it.	Assessor asks staff to explain their responsibilities and the review process. Finding: staff are unaware the policy exists or describe a different process.
Findings ownership	Who decides whether a determination is met, partly met or not met.	The independent assessor issues the findings. DeployOpen prepares systems and evidence but does not issue assessment results.

How to write, approve and maintain the SI policy in sequence

This sequence turns SI-1 from a document requirement into a working policy set that names an owner, covers each SI practice in use, is approved and acknowledged by the people who run it, and is reviewed on a calendar and after defined events. Each step ends with an artifact you can hand to an assessor.

Confirm the policy level and baseline
Decide whether the policy applies at organization, mission or business process, or system level, and confirm which SP 800-53B baseline (low, moderate, high or privacy) applies to the systems in scope. The SI-1 assignment follows the baseline, so this step fixes what the policy must cover. The lead is usually the compliance or security governance function, with system owners confirming their impact level. It is done when a scope statement names the systems, the policy level and the baseline, and the organization has signed off on that scope.
Name the designated official
Assign one named official who manages the SI policy and procedures and is accountable for keeping them current. This role should sit high enough to approve resources and low enough to know how patching, malware protection and monitoring actually run. Record the appointment in the governance records so an assessor can match the role to the document owner. The output is a written appointment that names the person, the role and the systems they cover.
Inventory existing SI practices
Document what the organization already does for flaw remediation, malicious code protection, system monitoring, security alerts, integrity verification and input validation. Ask each practice owner which tools, schedules and responders they use and where the records are kept. Gaps and informal habits will show up here, and they should be recorded rather than smoothed over. The output is an inventory table with one row per practice, its owner, its tooling and its current evidence source.
Draft the policy and procedures
Write the policy as a statement of purpose, scope, roles, management commitment and the SI areas it governs, then write procedures that describe how each practice is carried out. Use the organization-defined parameters in SI-1 to set values such as review frequency and the events that trigger review, and align the wording with the practices you inventoried. Keep the policy short enough to be read and the procedures specific enough to be followed. The output is a draft policy and a set of procedures, each linked to the SI control it implements.
Map each procedure to an owner and runbook
For every procedure, name an accountable owner, a backup, and a runbook that lists the steps, tools and records. Runbooks for patching, anti-malware updates, alert triage and integrity checks are where assessors look for proof that a procedure works in practice. Store runbooks in a version-controlled wiki or documentation platform so changes and approvals are traceable. The output is a procedure register that links each procedure to its owner, its runbook and its evidence location.
Approve and disseminate the policy
Route the policy and procedures through the approval body the organization uses for governance documents, and record the approver and approval date on the document. Then distribute the approved versions to the defined roles, such as system owners, operations, security operations and development leads, through the channel those roles use. The output is an approved, dated version and a distribution list that matches the roles named in the policy.
Record acknowledgments from defined roles
Ask each role on the distribution list to acknowledge that they have received and understood the policy and the procedures that apply to them. Track acknowledgments by name and date, and chase missing ones through the reporting line. Acknowledgments are simple evidence, but they show that the dissemination step reached the people who do the work. The output is an acknowledgment register that shows who received which version and when.
Set the review calendar and event triggers
Put the review frequency defined in the policy on a calendar owned by the designated official, and add event triggers such as major incidents, significant system changes, new external directives and changes to the authorization boundary. Each review should record what was checked, what changed and which version was approved. Changes to SI-1 and to the linked procedures also trigger a new distribution and acknowledgment cycle. The output is a review log with dated entries, approvals and version history that an assessor can follow from one cycle to the next.

Evidence that passes SI-1 and how to keep it current

An assessor testing SI-1 looks for a policy that is approved, disseminated, reviewed on a schedule and traceable into the procedures that run patching, malware protection, monitoring and integrity checks. The cards below list the artifacts that show this, and how to keep each one current between formal assessments.

Approved SI policy with version history

The system and information integrity policy itself, with a named official, an approval date, an approver and a version history showing each change. Confirm that the policy states its scope (organization, mission or business process, or system level) and that the nine organization-defined parameters in SI-1 are filled in with actual values, not placeholders. Store it in a wiki or document system that records who changed what and when, so the current version and its predecessors can be produced on request. Tie each revision to a change ticket so the history explains itself.

Procedures with named owners

Implementing procedures for patching, malware protection, monitoring and integrity verification, each with a named owner, a review date and the steps an operator follows. An assessor compares these against the policy and checks that every policy statement has a procedure behind it. Keep procedures in the same versioned system as the policy so reviewers can compare any two versions. Where a procedure depends on a tool, name the tool and the configuration file or dashboard that proves it runs.

Dissemination and acknowledgment records

Evidence that the policy and procedures reached the roles that must follow them, such as platform engineers, security operations staff and system owners, with a dated acknowledgment from each. Define the recipient roles in the policy itself, then export the acknowledgment list from your document or learning platform. Check for gaps: staff who joined after the last issue, contractors with access to self-hosted systems, and people who changed roles. A list that does not match the defined roles will fail an interview.

Review log with triggering events

A dated log of each review of the policy and procedures, recording who reviewed them, what changed and what caused the review. SI-1 expects reviews at a defined frequency and after defined events, so record both scheduled reviews and event-driven ones such as a significant incident, a new platform added to scope or a change in the patching process. Link entries to incident reviews and change tickets so the log shows the policy responding to real events rather than only to the calendar.

Exception and deviation records

Documented exceptions where a system cannot follow a procedure, such as a legacy component that cannot receive a patch within the standard window. Each record should name the affected system, the reason, the compensating measure, the approver, an expiry date and the review that will close it. Assessors look for exceptions with no expiry or owner, because they suggest the policy is not enforced. Review open exceptions at every policy review, and retire any that a change has resolved.

Traceability into SI-2, SI-3, SI-4 and SI-7

A cross-reference matrix showing that the flaw remediation (SI-2), malicious code protection (SI-3), system monitoring (SI-4) and integrity (SI-7) procedures each trace back to a policy statement. Maintain it as a table with one row per policy statement and a link to the procedure and evidence for each. When a procedure changes, the matrix is the first thing to update, and a missing link is an easy finding to catch before an assessment. Confirm that each linked procedure has a current owner and review date.

What meeting SI-1 costs in money and effort

This table breaks the SI-1 policy and procedures effort into its cost components, showing who does the work, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to see where open-source document tools can replace license spend. NIST does not estimate compliance costs, so every figure must come from your own scope and a written quote.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Policy drafting and approval	Policy owner, security lead, legal or privacy reviewers	One-time, then recurring on each revision	Up: number of baselines and privacy scope. Down: reusing existing enterprise policy text
Designated official time	Named official who manages the SI policy and procedures	Recurring	Up: many systems or business units needing sign-off. Down: one organization-level policy with system-level annexes
Procedure writing for SI family	Engineers and operations leads who document patching, malware, monitoring and integrity steps	One-time, then recurring as tools change	Up: number of SI procedures and teams owning them. Down: linking to existing runbooks instead of copying them
Document version control tooling	Vendor licenses or self-hosted platform hosting and administration	License recurring or hosting one-time setup plus upkeep	Up: per-seat licensing across many users. Down: self-hosted open-source wiki with built-in version history, subject to confirmation of your own requirements
Dissemination and acknowledgment	Administrators who distribute the policy and collect staff acknowledgments	Recurring with each revision and new joiner	Up: large or distributed workforce and many contractors. Down: acknowledgment built into the document platform or identity workflow
Scheduled and event-driven review	Policy owner and procedure owners, plus approvers	Recurring at the defined frequency and after defined events	Up: short review cycles and many triggering events. Down: defined trigger list tied to change control
Assessor sampling and interviews	Independent assessor time, plus staff time to answer and produce evidence	Recurring at each assessment cycle	Up: more systems in the assessment sample and unclear ownership. Down: a current, indexed evidence set ready before testing
External drafting or review	Outside consultant or legal counsel, paid per written scope	One-time for initial drafting, occasional thereafter	Up: starting from no policy and needing legal review. Down: an internal draft that the consultant only checks

Open-source tools that hold SI-1 policy and evidence

SI-1 is a documentation control at its core, so the tools you choose determine whether policy versions, approvals and assessment results can be shown to an assessor. The three tools below cover different parts of that evidence: the policy text itself, who may read and change it, and the mapping of procedures to the framework. Each runs inside your own infrastructure, and none of them replaces your own policy decisions or an independent assessment.

XWiki for policy version history

XWiki keeps every change to a page under version control, recording what changed, when and by whom. You can compare any two versions and roll back to an earlier one, which lets you show an assessor the exact SI-1 policy text in force on a given date. Confirm that your deployment's page history is retained long enough to cover your review cycle, and that approval records are kept separately, because a version log shows edits but not who authorized them. Check the license terms (LGPL-2.1-or-later) before modifying and redistributing XWiki code.

BookStack for role-based access

BookStack derives user abilities from assigned roles and lets you override permissions per role at the shelf, book, chapter or page level. For SI-1, this separates the people who maintain the system and information integrity policy from the staff who only need to read it. Confirm that edit rights on the policy book are limited to the designated official and approvers, that default roles do not grant broad editing, and that you review role assignments on the schedule your policy sets. BookStack records page history, but you should confirm its retention and export behavior in your version before relying on it as an audit trail. The MIT license places few conditions on use.

CISO Assistant for framework assessments

CISO Assistant ships more than 200 frameworks, including NIST CSF, and can run audits and compliance assessments against them with automatic mapping between frameworks. For SI-1, it can hold the policy and procedure requirements, link them to evidence such as the policy page and review records, and track assessment status. Treat automatic mapping as a starting point: confirm each mapping against the NIST text and your own scope before reporting it, because a mapping that is wrong will pass unnoticed in a tool. Confirm which framework library and version your instance loads. CISO Assistant is licensed under AGPL-3.0-only, so review the license obligations before offering it to users over a network.

License obligations for LGPL and AGPL

The three tools carry different licenses, and they matter in different ways. XWiki's LGPL-2.1-or-later and CISO Assistant's AGPL-3.0-only are copyleft licenses, so modifications you distribute, and in the AGPL case modifications you make available to users over a network, can trigger source disclosure duties. BookStack's MIT license is permissive. Ask counsel to confirm how your planned use, including internal-only hosting and any customization, falls under each license before you start the implementation. Do not assume that running the software internally carries no obligations.

Who owns SI-1 in-house, who can help and who assesses

The organization owns SI-1. A designated official, usually a senior security or risk leader, is accountable for the system and information integrity policy and its procedures. A named policy owner maintains the document, tracks its review cycle and records approvals. Engineering leads for patching and monitoring own the procedures that the policy governs, because they know how flaws are found, tested and deployed and how alerts are triaged. Staff who must follow the policy acknowledge it, which creates the dissemination record SI-1 asks for.

Designated official: Approves the policy and procedures, sets the review frequency your organization defines and decides what triggers an out-of-cycle update.
Policy owner: Keeps the document current, maintains version history and links each SI family procedure to its responsible team.
Engineering leads: Write and run the operational procedures for patching, malware protection, monitoring and integrity checks that SI-1 governs.
Acknowledging staff: Confirm receipt and understanding, and the acknowledgment records are retained as evidence.

Confirm internally who holds each role before any outside party is engaged, since an implementation partner cannot approve policy on your behalf.

Where SI-1 usually fails and how to close each gap

SI-1 is rarely missing outright. Most assessments fail on the details that connect a written policy to people and systems that act on it. The cards below cover six gaps an assessor is likely to test, with the fix and the evidence that closes each one.

Policy with no named official

The policy names a department but no individual who owns it, so nobody is accountable for reviews or exceptions. SI-1 requires a designated official to manage the policy and procedures. Name one person by role and title, record the appointment, and confirm that the official can approve changes. Evidence: the signed policy showing the owner, and a board or management record of the designation.

Procedures for tools no longer in use

Procedures still describe a patch server, scanner or monitoring console that was retired or replaced, so staff follow steps that no longer run. Compare each procedure against the current asset inventory and tool configuration, then update or retire it. Evidence: procedures with current tool names, a change record for each update, and a walkthrough showing staff performing the steps as written.

Review dates that lapsed

The policy states a review frequency, but the last review predates a reorganization, a new system or a significant incident. SI-1 requires review at a defined frequency and after defined events, so both triggers must be written down and tracked. Set the review date in a shared register and link each trigger to the change process. Evidence: version history with dated reviews and a register showing the next due date.

No record of dissemination

The policy exists in a document library, but there is no proof that the defined roles received it or acknowledged it. Assessors look for evidence that the policy reached the people it governs, not only that it was published. Distribute to named roles, collect acknowledgments, and keep the list current as staff change. Evidence: distribution lists, dated acknowledgments and a log of new-role onboarding.

Policy written at one level, applied at another

The policy is drafted at organization level, but system owners run their own patching and monitoring rules that contradict it. SI-1 allows policy at organization, mission, process or system level, so the level must match what is actually in force. Map each system to the policy it follows and document any system-level variation. Evidence: a scope statement and a system-to-policy mapping signed by the official.

No link to SI-2 through SI-7 routines

The policy states that flaws, malware and integrity issues will be managed, but no procedure ties it to the SI-2 through SI-7 routines that do the work. An assessor will trace from the policy to a patch cycle, a malware update job or an integrity check and find nothing. Write a cross-reference from each procedure to its control and its evidence source. Evidence: a traceability table linking the policy to each SI routine and its records.

Questions buyers ask about SI-1 cost, effort and outside help

How much effort does a first SI-1 policy take?

A first SI-1 policy is mostly a writing and alignment task, and the effort depends on how much of the SI family already has written standards behind it. The policy has to name an owner, define scope at the organization, mission or system level, set a review frequency and list the events that trigger an update. The procedures underneath it have to describe how patching, malware protection, monitoring and integrity checks actually run. Organizations with existing vulnerability management, endpoint and logging standards usually need to reconcile and reference them. Organizations starting from nothing need interviews with the teams that operate these controls. Ask any quote to separate drafting, stakeholder review and the mapping of procedures to the SI controls that depend on them.

How long does it take to get an SI-1 policy approved and reviewed?

Approval time is driven by the number of reviewers and the governance path, not by the drafting itself. A policy typically moves through the security function, IT operations, legal or privacy, and an executive or risk committee that signs it. Each group may request changes, and each change restarts part of the cycle. SP 800-53 requires the policy to be reviewed and updated at a frequency and after events the organization defines, so the approval workflow should also be written down and repeatable. Confirm with your own governance calendar how many committee meetings fall between draft and signature, and plan for at least one revision round.

What does the work need from the compliance lead and engineering?

The compliance lead owns the policy document, its designated official, the review schedule and the evidence trail that shows the policy was disseminated and reviewed. Engineering owns the procedures, because patching cadence, scan configuration, log sources and integrity tooling are technical facts that a policy cannot invent. In practice the compliance lead needs time to define roles and approval steps, while engineering needs to confirm what runs today, who runs it and where records live. A short working session with each operating team usually surfaces the gaps faster than written questionnaires. Expect the engineering input to be the larger share of effort if tooling is undocumented.

Can an in-house team write SI-1 without an implementation partner?

Yes, an in-house team can write SI-1 if it has someone who understands the SI family and can describe the operating controls accurately. The policy is a governance document, and the organization owns it either way. A partner adds value where the team lacks the time or the technical reach to document systems, collect evidence and prepare the procedures for an assessor. The SP 800-53A assessment for SI-1 is examine and interview based, so the assessor will read the policy and ask staff how it works. Organizations should test their own readiness by asking whether every person named in the policy can explain their role without reading the document.

What should an implementation partner do for SI-1, and what should it not do?

A partner should prepare the policy and procedures, map them to the systems in scope, document how the SI controls operate, and assemble the evidence an assessor will request. It should not decide the organization's risk acceptance, sign the policy on the organization's behalf or claim that the policy satisfies a certification. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure and prepares systems and evidence for assessments. Only an independent auditor, assessor or certification body issues reports or certificates. Engagements are fixed-scope, so the written scope should list the documents, systems and interviews included before work starts.

Is SI-1 tested on its own or together with the rest of the SI family?

SI-1 is assessed on its own, but its procedures are only credible when the other SI controls are tested against them. SP 800-53A gives SI-1 its own determination statements, which the assessor checks through examination and interviews. The assessor will then look at whether the procedures for flaw remediation, malicious code protection, system monitoring and integrity verification describe what actually happens. A policy that is detailed but contradicted by configuration or logs will fail the review of the operating controls, even if SI-1 itself passes. Plan for SI-1 to be the first document reviewed and the one every other SI test is traced back to.

Does a policy alone satisfy the other SI controls?

No, a policy alone does not satisfy the other SI controls. SI-1 requires documented policy and procedures, but controls such as SI-2 and SI-3 require that the activities happen, are measured and leave records. An assessor will expect configuration settings, scan results, patch records and alert handling evidence that match what the policy says. Any control whose procedure names a tool, cadence or owner needs proof that the tool is running and the owner acts. Treat the SI-1 policy as the contract that the operating controls must meet, and budget effort for the evidence that proves each control runs.

How DeployOpen scopes and prepares SI-1 evidence

DeployOpen helps teams turn SI-1 Policy and procedures into a working, reviewable document set inside their own infrastructure. We prepare the policy, procedures and evidence trail; the organization owns the policy, and an independent assessor decides whether the control is met.

How we scope

Agree in writing which systems, business processes and policy levels the SI-1 policy covers.
Confirm the designated official, the disseminated roles and the review frequency your organization has chosen.
List the SI family controls (patching, malware protection, monitoring, integrity) the policy must reference in its scope.

How we build

Draft the SI-1 policy and implementing procedures for your review, mapped to the organization-defined parameters you set.
Configure self-hosted documentation so every policy version keeps a record of changes, authors and dates.
Set up role-based access so only approved owners can edit or approve the SI policy and procedures.

How we hand over

Deliver the approved policy, procedures and a document index showing where each SI-1 assessment determination is evidenced.
Provide a runbook for the review cycle, including the triggers that require an out-of-cycle policy update.
Walk your assessors through the evidence trail, noting which items remain the organization's responsibility to maintain.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and documentation maintenance are available as a retainer.
Ask any provider to confirm in writing which SI-1 items they prepare and which the auditor or assessor must issue.