PM-31 Continuous monitoring strategy: evidence guide

What PM-31 continuous monitoring strategy asks for across the organization

If an assessor, a customer contract or a privacy baseline requires PM-31, the question is not whether your teams monitor their systems. It is whether the organization has one written continuous monitoring strategy and program that sets organization-wide metrics, monitoring and control assessment frequencies, carries out ongoing monitoring, correlates and analyzes the results, takes response actions and reports the security and privacy status of systems to defined personnel at a defined frequency. PM-31 is an organization-wide strategy and program, not a per-system checklist. Many organizations have per-system monitoring with no shared strategy behind it, and that gap is what this control tests. PM-31 belongs to the Program Management family. NIST describes these controls as deployed across the organization to support the information security program, so they are not allocated to the low, moderate or high control baselines in SP 800-53B, which are selected by system impact level. PM-31 is the exception that matters for privacy: it is included in the privacy control baseline, which applies to systems regardless of impact level. A team that scopes its program by impact tier alone can miss it entirely. Confirm with your assessor or contract owner which baseline or privacy requirement they are citing before you plan the work.

The risk PM-31 addresses is a loss of visibility. When logs, vulnerability results, configuration data and access reviews sit in separate tools owned by separate teams, no one can state the security and privacy posture of the whole estate or see which findings are trending in the wrong direction. The difficulty is less about buying tools than about agreeing on what gets measured, how often each control is assessed, who acts on a result and who receives the status report. Start by listing every monitoring source, its owner and its current reporting cadence, then identify the officials who need the consolidated view. Open-source options such as Wazuh, OpenSearch Security Analytics and DefectDojo can each produce parts of that picture, but the strategy document and the reporting decisions are still the organization's to make.

Which systems, teams and third parties PM-31 covers

PM-31 sits at the organization level, so its scope questions are about what the program covers, not just which systems get scanned. The cards below separate the decisions that shape the strategy: how organization-wide monitoring relates to system-level ISCM under CA-7, when the privacy baseline status from SP 800-53B applies, who owns metrics and reporting, and how supply chain monitoring is brought in.

Organization-wide strategy versus system-level ISCM

PM-31 asks for one organization-wide continuous monitoring strategy and program, while CA-7 asks each system's monitoring to follow that strategy. Decide which metrics, assessment frequencies and reporting rules are set once for the whole organization and which are tailored per system. Check that every system's monitoring plan traces back to the organizational strategy, and that a system added later inherits those rules without a separate design exercise. Confirm the boundary with your assessor before the first assessment.

Whether the privacy baseline applies

SP 800-53B includes PM-31 in the privacy control baseline, which applies to systems regardless of impact level, and does not allocate it to the low, moderate or high security baselines. Confirm with your privacy office which systems process PII and therefore fall under the privacy baseline. Systems that handle PII need their monitoring evidence to cover privacy status as well as security status. Record the baseline status for each system in your inventory so reviewers can see why a system is or is not in scope.

Ownership of metrics and reporting

PM-31 requires status reporting to defined officials at a defined frequency, and the assessment procedures name interviews with the Senior Accountable Official for Risk Management and the chief information officer. Decide who sets the organization-wide metrics, who collects the underlying data, and who signs off the status report. Write these roles into the strategy so that a metric has one owner. Without named owners, the same gap tends to be reported by several teams and fixed by none.

Monitoring of data sources across systems

Correlation and analysis under PM-31 only work when logs, scan results and assessment findings arrive in one place. Decide which systems feed the monitoring program, which log types and finding sources are required, and how results from different tools are normalized. Open-source tools such as OpenSearch Security Analytics and Wazuh can correlate events across log types, but you need to confirm that each source you rely on is onboarded. Treat any system missing from the feed as a documented gap, not an assumed pass.

Supply chain monitoring under SR and PM-30

PM-31 explicitly reaches the supply chain risk management program, so monitoring must cover suppliers and the components they deliver, not only systems you operate. Decide which supplier assessments, notifications and component checks feed the continuous monitoring program, and how those results reach the same reporting channel. The related PM-30 strategy and the SR family define the inputs. Confirm which suppliers are considered critical and how their status is tracked over time.

Findings lifecycle across tools

Assessment findings from scanners, pen tests and audits can repeat across tools and reporting cycles. Decide how duplicates are identified, who approves closure, and how open items move into plans of action and milestones under PM-4. DefectDojo can import findings from many tool report formats and deduplicate them, which supports this step, but the deduplication rules and closure authority are still organizational decisions. Confirm these rules before the first monitoring cycle so that status reports count each finding once.

How an assessor tests PM-31 continuous monitoring strategy

This table shows how an assessor applies the SP 800-53A examine, interview and test methods to PM-31, which determination area each method covers and what evidence tends to fall short. Read it as a checklist for preparing artifacts before an assessment begins.

Assessment element	What the assessor does	Evidence that passes	Where it usually fails
Examine: strategy and program documents	Reads the organization-wide continuous monitoring strategy and the information security continuous monitoring program documentation	Approved strategy that names monitoring objectives, assessment frequencies, roles and the link to the risk management strategy	Strategy exists only as a document that no program activity follows
Examine: metrics and reporting artifacts	Checks that organization-wide metrics are defined and that reports show monitoring and assessment results	Metric definitions with owners, data sources, collection frequency and dated reports	Metrics with no owner or no defined threshold for response
Examine: supply chain risk management plan	Confirms the SCRM plan is consistent with continuous monitoring of suppliers and supply chain risk	SCRM plan section showing supplier monitoring frequency and escalation path	Supplier monitoring described in the plan but never performed or recorded
Interview: Senior Accountable Official for Risk Management	Asks how monitoring results inform risk decisions and who receives status reporting	Consistent answers that match the strategy, plus records of decisions taken on reported results	Officials cannot describe the program or point to a recent decision based on monitoring
Interview: chief information officer	Asks how monitoring is funded, staffed and integrated with system operations	Named owners, resourcing decisions and evidence that monitoring feeds operational change	Monitoring treated as a security team task with no operational integration
Test: organizational procedures and mechanisms	Observes whether monitoring procedures and tooling run as documented across information security, privacy and supply chain monitoring	Tool outputs, scheduled jobs, ticket trails and correlated findings from a sample period	Procedures exist on paper while tooling is unconfigured or alerts are not triaged
Test: reports reaching defined officials	Traces a sample of status reports from generation to the defined recipients and the defined frequency	Distribution records, acknowledgment or meeting minutes, and reports on the agreed cadence	Reports never reach the defined officials or arrive late with no record of follow-up
Test: response actions	Follows monitoring results through to response actions and their closure	Open and closed actions linked to results, with dates and owners	Findings logged but no response actions recorded or closed

Implementing PM-31: the sequence and the output of each step

This sequence turns PM-31 from a documented intent into a running organization-wide program, with each step producing an artifact that an assessor can examine, interview against and test.

Confirm roles and accountable officials
Confirm who holds the Senior Accountable Official for Risk Management role and who acts as the chief information officer for continuous monitoring, and record how responsibilities split between them and the information security and privacy programs. SP 800-53A lists both roles as interview subjects for PM-31, so their responsibilities must be written down and reachable. The organization owns this decision; an implementation partner can draft the role descriptions for leadership to approve. The step is done when a signed role statement names each official and the duties assigned to them.
Define organization-wide metrics and frequencies
Set the metrics the program will track across systems, such as control assessment status, open monitoring findings and supply chain risk indicators, and assign a monitoring or assessment frequency to each. Each metric needs a defined owner, a data definition and a threshold that triggers review. PM-31 requires frequencies to be set at the organization level, so the catalog should cover all systems rather than one project. The output is an approved metrics catalog with frequencies, owners and definitions, which becomes the reference for later monitoring and reporting.
Inventory data sources and assessment activities
List every source that feeds monitoring results, including log platforms, vulnerability scanners, configuration tools, identity systems and assessment records, and list the assessment activities that produce control evidence. For each source, record the system it covers, the owner, the format and the metrics it supports. Cross-check the inventory against the system inventory under PM-5 so that no in-scope system is missing. The output is a source inventory that shows where each metric comes from and where gaps remain.
Set correlation and analysis rules
Define how results from different sources are compared, grouped and analyzed, such as linking an authentication anomaly to a configuration change or a scanner finding to an asset owner. Write the rules as detection logic or analysis procedures, record which findings are deduplicated and how, and state who reviews correlated results. Open-source platforms such as OpenSearch Security Analytics and Wazuh can hold rule content, but the organization must confirm each rule and its tuning. The output is a versioned rule set with documented analysis procedures.
Define response actions and escalation paths
Write a runbook that states the response action for each class of finding, the severity at which it escalates, the person or group who acts and the point at which the risk goes to a formal decision. Link each path to existing incident response and plan of action and milestones processes so that accepted risks and open remediation items are tracked in one place. The runbook is complete when every metric in the catalog has a response action and an escalation owner.
Set the status reporting cadence and recipients
Decide what security and privacy status is reported, to whom, and how often, based on the defined officials and the frequency the organization sets. Specify the report contents, such as metric trends, open findings by system and accepted risks, and the format each recipient receives. PM-31 expects reporting to defined personnel at a defined frequency, so the distribution list and calendar must be approved and recorded. The output is a reporting schedule with named recipients and a report template.
Run and date the first full cycle
Execute the strategy end to end once: collect data from every listed source, run the correlation rules, apply the runbook to the results, and issue the first status report to the defined recipients. Record the date each activity was performed and retain the raw outputs, so the cycle itself becomes evidence. Review the gaps the cycle exposes and feed them back into the source inventory and metrics catalog. The step closes when a dated report exists, the recipients have received it and the open gaps are logged for the next cycle.

Evidence that satisfies PM-31 and how to keep it current

PM-31 is judged on documents and records that show an organization-wide strategy exists, runs and reaches decision makers. The artifacts below connect to one another, so a gap in one (for example, metrics with no owners) usually shows up as a gap in another. Each card names what to keep current between assessments.

Approved continuous monitoring strategy

This is the organization-wide document that sets what is monitored, why, by whom and how often. Assessors look for an approval record from the accountable official, a scope that covers security, privacy and supply chain monitoring, and links to the metrics and frequency schedule. Keep it under version control with a named owner, a review date and a change log that records each revision and the reason for it. Check that the version in circulation matches the approved one.

Metrics catalog with owners and targets

A catalog lists each metric, how it is calculated, its data source, its owner and its target or threshold. Assessors test whether metrics actually drive decisions, so each target should trace to a risk tolerance or policy statement. Review the catalog when systems, data sources or risk tolerance change, and record the date and reason for each edit. Retired metrics should stay in the history with the reason they were dropped.

Monitoring and assessment frequency schedule

The schedule sets how often each control or group of controls is monitored and assessed, and which teams perform the work. It should be consistent with the strategy and with any authorization or contract obligations that set minimum frequencies. Keep dated execution records next to the schedule so a reader can see planned versus completed work. Recheck the schedule after major changes to systems or threats, and log every frequency change with the approver.

Dated status reports and distribution records

Status reports show the security and privacy posture of systems to the officials the strategy names, at the frequency it defines. Assessors will ask for several consecutive reports, not one, and for proof that each reached its recipients, such as distribution lists, meeting minutes or ticket acknowledgments. Keep reports in a dated archive and confirm the recipient list against the roles named in the strategy each time it changes.

Correlation and analysis outputs

Correlation outputs show that monitoring results are linked and analyzed, not just collected. Examples include detector findings, correlated alert groups and analyst notes that connect events across log sources. Self-hosted tools such as OpenSearch Security Analytics and Wazuh can export findings and alerts for this purpose, but you must confirm the export format and retention in your own environment. Keep saved queries, rule versions and dated triage notes so the analysis can be reproduced.

Response action tickets with closure

Each finding that needs action should become a ticket with an owner, a due date, the response taken and evidence of closure. Assessors sample tickets to confirm that responses follow from monitoring results and that overdue items are escalated. Tools such as DefectDojo can deduplicate and track findings across imports, which helps keep one finding from appearing as several open items. Keep the closure evidence attached to each ticket and retain the history rather than deleting closed items.

Supply chain monitoring records

PM-31 covers supply chain monitoring as well as system monitoring, so the program should record checks on suppliers and components tied to the supply chain risk management strategy. Typical records include supplier review results, vulnerability notices for third-party components and follow-up decisions. Review these on the schedule the strategy sets and log exceptions with their approvers. Confirm with your procurement and security leads which supplier signals they already collect, since those records often already exist.

What meeting PM-31 costs in money and effort

This table lists the cost components of an organization-wide continuous monitoring program under PM-31, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since no price or duration is published for these components.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Monitoring and SIEM tooling or licenses	Software vendor or cloud provider for commercial tools, or the organization for self-hosted platforms	Recurring for commercial licenses. Self-hosted open-source tools carry no license fee but still need infrastructure.	Log volume, number of monitored sources, retention period and whether the platform is hosted by the client or a vendor. Ask for licensing metrics in writing.
Engineering time to wire sources and build metrics	Internal platform or security engineers, or an implementation partner under a fixed-scope agreement	One-time for initial integration, recurring when new systems or sources are added	Number of systems in the organization-wide inventory, heterogeneity of log formats and how many metrics the strategy defines. Ask for a source-by-source integration list.
Governance time from the Senior Accountable Official and CIO	Internal executives and risk owners who approve the strategy, frequencies and reporting	Recurring at the review cycle the strategy sets, plus one-time for initial approval	Number of defined officials receiving status reports, how often the strategy is reviewed and how many risk decisions escalate. Clarify the review cadence before scoping.
Evidence upkeep	Internal compliance or security staff, and any partner preparing evidence packages	Recurring	Frequency of assessment and monitoring cycles, number of metrics with retained artifacts and whether evidence is generated automatically. Ask how artifacts are stored and versioned.
External testing or review	Independent testers or assessors engaged by the organization	Recurring where the strategy requires periodic outside testing, one-time for initial benchmarking	Scope of systems tested, testing depth and frequency set by the organization. Ask whether testing is scoped separately from the monitoring program.
Auditor sampling	Independent assessor or auditor, paid by the organization	Recurring at each assessment cycle	Number of monitoring records the assessor samples, how complete the metric history is and how many findings require follow-up. Clean, complete records usually reduce sampling effort.
Open-source tooling effort	Internal operators or an implementation partner for hosting, upgrades and tuning	Recurring operating effort, with one-time setup	Platform sizing, patching cadence, rule tuning and on-call coverage. Self-hosting removes license spend but adds operating effort that should be budgeted explicitly.

Who owns PM-31, who can help and where the auditor stops

Your organization owns PM-31. The continuous monitoring strategy is an organization-wide document that sets what gets measured, how often controls are assessed and monitored, and who receives status reports. Those choices reflect your risk tolerance and mission, so they cannot be delegated to a vendor or consultant. Your team also decides how monitoring results are acted on and who is accountable when they are not.

Strategy and frequencies: Approve the organization-wide metrics and the assessment and monitoring frequencies, and record the rationale for each.
Response decisions: Define who triages monitoring results, who authorizes response actions and how exceptions are approved.
Reporting lines: Name the officials who receive security and privacy status reports and the frequency of those reports.
Program records: Keep the strategy, meeting minutes, metric reviews and decision logs that show the program operates.
Staffing: Confirm the roles for the Senior Accountable Official for Risk Management and the chief information officer, since assessors interview them.

Before engaging anyone, confirm that a named owner can explain the strategy in an interview without reading from a vendor document.

Open-source tools that produce PM-31 evidence

PM-31 asks for an organization-wide continuous monitoring program, so its evidence comes from several places at once: security event detection, vulnerability and finding management, and framework-level assessment tracking. The four tools below each produce one part of that record. None of them satisfies PM-31 on its own, and each capability should be confirmed in your own environment before you rely on it.

OpenSearch Security Analytics

OpenSearch Security Analytics (Apache-2.0) runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. A correlation engine links findings across log types in a correlation graph, which can show whether monitoring results connect across the estate. Confirm that your log sources, rule sets and alert routing match the monitoring frequencies your strategy defines.

Wazuh ruleset and alerts

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for dashboard review, and alerts are mapped to MITRE ATT&CK. This gives you alert records that show what was monitored and what was flagged. Check that the built-in rules cover the systems in your inventory, and document any custom rules as part of the monitoring strategy.

DefectDojo findings management

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and also accepts a generic findings import. It deduplicates findings using per-tool hashcode fields, so repeated scan results do not inflate the record. The result is a single register of findings that can support status reporting to defined officials. Confirm that the report formats you rely on are supported in the edition you deploy, and test deduplication with your own scanner output.

CISO Assistant framework tracking

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including NIST CSF, ISO 27001 and SOC 2, and runs audits and compliance assessments against them with automatic mapping between frameworks. For PM-31, it can hold the continuous monitoring strategy, the assessment frequencies and the status reports as tracked records against the relevant control. Treat the mappings as a starting point and verify any mapping your assessor will rely on, since the tool's automatic mappings are not a NIST-supplied crosswalk. The AGPL-3.0-only license requires review by your legal team if you modify and offer the software to others.

What a PM-31 strategy document has to decide, not just describe

A PM-31 strategy is a decision record before it is a description. An assessor reading it will look for who chose each organization-wide metric, how often each monitoring and control assessment activity runs, who reviews correlated results, what happens when a metric crosses a threshold, and who receives status reports on security and privacy posture. A document that lists monitoring tools without answering those questions gives the assessor nothing to test. Start by writing the decisions as numbered statements with an owner, a frequency and a trigger for each, then attach the policies and procedures that carry them out. The control also expects the strategy to cover supply chain continuous monitoring and privacy, so the decision list should include those areas explicitly.

PM-31 operates above the individual system. CA-7 asks for continuous monitoring of each system's controls, and the system-level ISCM activities feed the organization-wide strategy. The distinction matters for ownership: a system owner can decide how a single application is scanned, but only the organization can decide which metrics roll up to the senior accountable official, how breaches are escalated across business units, and whether a privacy metric carries the same weight as a vulnerability metric. Confirm with your assessor and your own governance documents how the organization-wide strategy and the CA-7 procedures reference each other, so one does not quietly contradict the other.

For mapping work, NIST's OLIR catalog lists PM-31 as an informative reference for seven CSF 2.0 subcategories: GV.OV-01, GV.OV-02, GV.SC-03, GV.SC-09, GV.SC-10, ID.IM-02 and ID.IM-03. NIST marks that crosswalk as not comprehensive, so treat it as a starting point for your own traceability matrix, not as proof that a CSF subcategory is fully met. Any CSF claim should be checked against the subcategory text and your evidence set. Keep the strategy document, metric definitions and review minutes in one controlled location so the same artifacts can answer both the NIST and CSF questions without duplicate work.

PM-31 questions buyers ask before bringing in outside help

How much effort does PM-31 take, and can we do it in-house?

Yes, most organizations can build PM-31 in-house if they have staff who own the monitoring strategy, metrics and reporting. The effort is driven by how many systems feed the program, how many data sources need correlating, how mature current monitoring is, and how many officials receive status reports. Recurring work includes reviewing metrics, running assessments at the frequencies you set, triaging results and producing status reports. Ask any outside party to quote the one-time work (strategy design, metric definitions, tool integration) separately from recurring support, and to state which deliverables they own versus which your staff must maintain. No public effort figure for PM-31 was supplied, so confirm sizing against your own environment before committing budget.

How long does it take to stand up a PM-31 program?

The timeline depends less on the control text and more on what already exists: a documented ISCM strategy, defined assessment frequencies, an inventory of systems, and monitoring tools that produce usable data. Organizations with those pieces mostly need to organize them around the PM-31 requirements. Organizations starting from scratch need decisions from the senior accountable official and the CIO before any tooling work begins. Your team will need a named owner, access to log and vulnerability data, and time from the officials who receive status reports. No duration figure was supplied for this work, so ask any partner to tie the schedule to a written scope with named deliverables and dependencies on your decision-makers.

Does PM-31 apply to low, moderate and high systems?

PM-31 is not allocated to the low, moderate or high baselines. SP 800-53B treats Program Management controls as organization-wide, supporting the information security program and independent of system impact level. PM-31 is included in the privacy control baseline, which applies to systems regardless of impact level. In practice, this means an agency or contractor under a moderate or high baseline still needs an organization-wide continuous monitoring strategy to support its system-level monitoring under CA-7, but the PM-31 requirement itself sits outside those baselines. Confirm with your assessor and contracting officer how the requirement is scoped in your authorization package, because contract language can add obligations beyond the baseline.

Can a security tool alone satisfy PM-31?

No. A tool can collect, correlate and report data, but PM-31 asks for an organization-wide strategy and programs, including metrics, assessment frequencies, response actions and status reporting to defined officials. Those decisions are management decisions that the organization must document and own. Open-source tooling can support the program in useful ways: OpenSearch Security Analytics can run Sigma-based detectors and correlate findings across log types, Wazuh can generate alerts mapped to MITRE ATT&CK, and DefectDojo can deduplicate and track findings from many scanners. Each tool still needs a documented role in the strategy, and the evidence must show that people acted on results. Confirm each capability in the current release before relying on it in an assessment.

What do assessors ask for first when they test PM-31?

Assessors following SP 800-53A start with the documents: the supply chain risk management plan, the continuous monitoring strategy, and the information security continuous monitoring program documentation, including reporting, metrics and artifacts. They then interview the Senior Accountable Official for Risk Management and the chief information officer about how the program works in practice. Finally, they test the procedures and mechanisms used for information security, privacy and supply chain monitoring. Prepare a strategy document that names metrics, frequencies and response owners, a dated set of status reports to defined officials, and sample records showing findings were correlated and acted on. Assessors determine the outcome; your partner can help assemble the evidence but cannot issue the assessment result.

Can the implementation partner also be our auditor?

No. An implementation partner prepares systems, controls and evidence, while an independent assessor or auditor evaluates them and issues the findings. DeployOpen plans, implements, integrates and documents self-hosted platforms in your environment and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Your organization owns its controls and decides who assesses them. Keeping those roles separate also protects the independence your authorizing officials and contracting parties will expect. When you request a quote, ask the partner to list exactly which evidence it prepares and which parties are responsible for review and sign-off.

What should a PM-31 quote include before work starts?

A useful quote lists scope, deliverables, exclusions, assumptions and timelines in writing before work begins. For PM-31, expect items such as a review of current monitoring and assessment practices, a draft continuous monitoring strategy, metric and frequency definitions, integration of selected open-source tools, evidence templates for status reporting, and knowledge transfer to your staff. Ask which parts are one-time and which are retainers for ongoing support, upgrades or continuous testing. Also ask what your organization must supply: system inventories, log access, named officials and review time. DeployOpen works from a fixed written scope and does not publish a price list, so the quote follows from the scope you agree on.

How DeployOpen prepares PM-31 evidence in your environment

DeployOpen works on PM-31 as an organization-wide program, not as a single system setting. We prepare the monitoring tooling, metrics and reporting records inside your own infrastructure so that your officials can show how the continuous monitoring strategy runs, while independent assessors decide whether it meets the requirement.

How we scope

Engagements are fixed-scope, with the PM-31 deliverables and boundaries agreed in writing before work starts.
The scope lists which systems, data sources and monitoring tools feed the organization-wide strategy and status reports.
Scope also names the defined officials and reporting frequency that the strategy must address, so ownership is clear from the start.

How we build

We deploy self-hosted monitoring and analytics platforms in your cloud accounts, data centers or air-gapped networks.
We configure metrics, assessment frequencies and alert routing so monitoring results can be correlated and reviewed over time.
We test the pipeline end to end, confirming that findings from scanners and log sources reach the reports that officials receive.

How we hand over

We document the continuous monitoring strategy, metric definitions, response procedures and reporting cadence for your staff.
We deliver evidence packages showing configurations, sample reports and review records that your assessor can examine.
Your organization keeps ownership of the strategy and control decisions, and an independent assessor issues any findings or reports.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
Retainers can cover tool upgrades, metric tuning and periodic checks that the monitoring program still produces usable status reports.
Ask for the support scope, response expectations and handover terms in writing before the retainer begins.