What CC5.3 policies and procedures requires in a SOC 2
An auditor who asks how your controls are deployed is really asking two things: whether your written policies set clear expectations, and whether people actually carry them out. CC5.3 addresses that second half. It restates COSO Principle 12, which expects an organization to deploy control activities through policies that set expectations and procedures that put them into action. A policy says what must happen, such as access reviews, change approvals or vendor reassessments. A procedure says who does it, how, and how often, and leaves evidence behind. Auditors look for both, and they test the link between them.
The points of focus under CC5.3 show where examinations usually find gaps. They look for policies that support management's directives, a named person who is responsible and accountable for each activity, timely performance rather than performance whenever someone remembers, competent personnel doing the work, corrective action when something fails, and periodic reassessment of whether the policy still fits the business. Points of focus are guidance for designing and evaluating controls, not separate requirements, but an auditor will still ask how each of these is handled in your environment.
The most common difficulty is a policy that exists but has no owner and no recurring activity behind it. A document may say that access is reviewed quarterly, yet no one is assigned to run the review, no calendar entry exists, and the last review record is undated. Before fieldwork, confirm that every policy in your set maps to a named owner, a defined procedure, a schedule, and a dated record of the last performance. Ask your auditor which evidence format they expect, because the same activity can be documented in a wiki, a ticketing system or a signed form, and the choice affects how easily samples can be pulled later.
Which policies, procedures and teams fall under CC5.3
CC5.3 applies to whatever the examination covers, so the first decisions are about boundaries: which system is in scope, which categories are included, and which outside parties run part of that system. Each card below is one decision that changes the set of policies, procedures and owners an assessor will expect to see.
Policies tied to the in-scope system
Start by listing the systems, people and data the report will describe, then map a policy to each area it governs, such as access, change, incident response and acceptable use. A policy with no in-scope system behind it is wasted effort, and a system with no policy is a gap an assessor will find. Check that every policy names the system boundary it applies to, and that the boundary in the policy matches the system description.
Procedure owners in each team
Each procedure needs a named owner who performs it, and a separate reviewer where the work could be self-approved. Engineering may own access provisioning, HR may own joiner and leaver steps, and operations may own backups. Confirm that every owner knows the procedure exists, has the authority to act, and has time allocated for it. Unowned procedures tend to lapse between audit periods.
Subservice organizations and their policies
When a cloud provider, hosting company or managed service runs part of the system, decide which of its controls your policies rely on and which you must perform yourself. Your policies should state what you expect from that provider and how you monitor it, such as reviewing its SOC report. Ask each provider for its current report and the complementary user entity controls it lists, then write procedures for the ones that fall to you.
Vendor and business partner requirements
Vendors with access to data or systems in scope need policy coverage for onboarding, due diligence, contract terms and offboarding. The policy should set minimum expectations, such as security terms in contracts and a review before access is granted. Procedures should record who approved each vendor and when access was removed. Check the vendor inventory against the system description so that no in-scope third party sits outside the policy.
Extra categories change the policy set
Security applies to every SOC 2, but adding availability, confidentiality, processing integrity or privacy brings criteria with their own policy needs. Availability may require capacity and recovery procedures, confidentiality requires disposal rules for confidential data, and privacy requires notice, consent and retention procedures. Decide which categories to include before writing policies, because each addition expands both the documents and the evidence an assessor will request.
Review cycle for each policy
Decide how often each policy is reassessed, who approves changes, and what triggers an earlier review, such as a new product, an incident or a change in regulation. Record the version history and approval date on each document. Confirm that the review dates fall inside the period the report covers, because an assessor will test whether reassessment actually happened.
How an assessor tests policies and procedures
This table compares what an assessor checks for each element of CC5.3, what evidence they request, and where organizations usually fail. Read it as a preparation checklist: each row is a test the assessor will likely run, so gather the matching evidence before fieldwork starts.
| Test area | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Policy ownership and review | Reads each policy for a named owner, approval, version and last review date, then compares the review date with the policy's own review cycle | Current policy set with approval history, owner assignments and the prior version kept under change control | Policy never reviewed since adoption, or owner has left the organization with no reassignment |
| Procedure coverage | Checks that each control in the control matrix has a written procedure that names the steps, the trigger and the performer | Procedure documents linked to the controls they support | Procedure exists in a policy statement only, with no steps a person can follow |
| Procedure performance over the period | For a Type 2, samples occurrences of each procedure across the observation period and checks they happened on time | Tickets, approvals, logs or sign-off records dated within the period for each sampled occurrence | Procedure ran in some months but not others, or gaps appear near the end of the period |
| Performer competence | Confirms staff who carry out procedures were trained on them and hold the skills or access the role requires | Training completion records, role descriptions and onboarding checklists for sampled performers | Procedure performed by contractors or staff who were never trained, or training predates a procedure change |
| Exception and corrective action | Traces a sample of exceptions or failed procedure runs to the corrective action taken and to any policy or procedure update | Exception log, root cause notes, remediation tickets and evidence the fix was verified | Exceptions logged without closure, or corrective action that does not change the procedure |
| Periodic reassessment | Checks whether management reassessed policies and procedures after incidents, audit findings or significant system changes | Meeting minutes, review sign-offs and change history showing what was reassessed and why | Policies reviewed on paper with no change record, even after a major platform change |
| Management representation | Compares the description of controls in the system description with what staff actually do in the sampled procedures | Management's written representations and the control matrix reviewed against procedure records | Description states a procedure is performed, but no occurrences appear in the sample |
Steps to deploy controls through policies and procedures
This sequence turns CC5.3 from a policy library into a working control set. Each control gets a written expectation, a named owner, a defined procedure and evidence that proves it ran, so an auditor can trace the path from policy to performance.
Map each control to a policy statement
Start from the control matrix and give every control a home in a policy. For each control, write one statement of management's expectation that names the control objective, the scope of systems and people it covers, and the risk it addresses. Controls with no policy statement are the first gap to close. Output: a matrix column that links every control ID to a policy section, with unmapped controls listed as open items for management to resolve.
Assign an owner for each procedure
Name one accountable owner for every control activity, meaning the role responsible for seeing that it happens, and separately name the performer if different. Owners should have the authority and time to act, and their names should appear in the policy or matrix, not only in a team chart. Output: a signed-off ownership table that an auditor can use to ask the right person for evidence.
Write procedures with frequency and performer
Turn each policy statement into a step-by-step procedure that states who performs the action, how often, with which tool, and what a completed action looks like. Keep procedures short enough that a competent new staff member can follow them without the author present. Output: a procedure document per control area in the wiki or document system, with a version history showing approval dates and who approved each change.
Train staff and confirm competence
Brief each performer and owner on their procedures, and record that the briefing happened. Where a procedure needs specialist skill, such as reviewing access logs or running a restore test, confirm the person has done it before or has supervised training. Output: training records tied to procedure versions, so you can show that the person performing a control was competent when they did it.
Set up recurring evidence capture
For each procedure, decide what record proves it was performed on time, such as a ticket, a signed review, a tool export or a log entry, and configure the system to capture it automatically where possible. Store evidence with the date, performer and reviewer. Output: an evidence calendar listing each control, the expected artifact, its location and the next due date, which becomes the population an auditor samples from.
Define corrective action for missed controls
Write what happens when a control is performed late, skipped or fails: who is told, how the cause is recorded, what fix is applied and how the owner confirms the fix worked. Track each exception to closure. Output: an exception log with dates, root cause, corrective action and closure evidence, which shows the organization identifies and resolves control failures rather than ignoring them.
Schedule periodic reassessment of policies
Set a review cycle for each policy and procedure, and trigger an earlier review after material changes such as new systems, new services, incidents or changes in regulation. Record each review outcome, even when nothing changes, and update the control matrix where needed. Output: a dated review register and approved revisions, confirming that policies reflect current operations and risk. The review interval should be set by the organization and confirmed against its own commitments and assessor expectations.
Evidence that passes CC5.3 and how to keep it current
Policies are the expectations management sets, so an assessor first checks that each one exists, has been approved by someone with authority, and states who owns it. Keep policies in a controlled location where every change is recorded. A wiki with version history is a practical choice, because it shows what changed, when, and by whom. Between audits, the main job is ensuring the version in use matches the version approved, and that superseded copies are not circulating in shared drives.
- Named owner and approver: Each policy names the role accountable for it and the authority that approved it, with the approval date.
- Version history: Changes are retained with author, date and a summary, so an assessor can compare the version in force on any date within the period.
- Single source: Staff and auditors are pointed to one controlled location, and older copies are archived rather than deleted.
- Mapping to controls: Each policy statement links to the control activity it supports, so the policy can be traced to operation.
- Access to the policy: Confirm that the people who must follow each policy can find it and that the platform's permissions reflect who may edit or approve it.
Check that every policy in the control matrix has an approved version covering the full examination period.
Procedures are the steps that put policy into action. The evidence that matters is a record showing that a specific task was performed, by a named person, on a specific date, against the documented procedure. Assessors sample these records across the period, so consistency matters more than volume. Procedure records are often generated by ticketing, deployment and access systems, and the job is to make sure those systems capture the performer and timestamp without manual reconstruction.
- Performer and date: Each record identifies who carried out the step and when, not only that a task exists.
- Link to the procedure version: Records should show which version of the procedure applied at the time.
- Segregation where required: Where a procedure needs a second person, the reviewer's sign-off is captured as a separate entry.
- Consistent sampling base: Keep the population complete so an auditor can select samples from the full period.
- Exceptions recorded: Steps skipped or performed late are logged with a reason instead of being quietly completed later.
A gap looks like a procedure that exists on paper but has no dated records, or records that were all created in one batch shortly before fieldwork.
CC5.3 points of focus include competent personnel, so assessors look for records showing that the people running controls understand their responsibilities. Training records should show who was trained, on what policy or procedure, when, and how their understanding was confirmed. Competence can also be shown through role descriptions, onboarding checklists and records of changes in responsibility. Keep these current as staff join, move roles or leave, because a control run by someone without the required training is a finding.
- Role-based requirements: Define which policies and procedures each role must complete, and record completion against that list.
- Dated completion records: Capture the date and the version of the material covered.
- Confirmation of understanding: A short assessment or attestation shows the person read and understood the expectation.
- Triggers for retraining: Record refreshers after a policy change or a relevant incident.
- Departures and transfers: Track when a role changes so responsibilities are reassigned and training is updated.
Confirm with your auditor how far back training records must reach and whether they expect records for contractors as well as employees.
When a control does not operate as designed, the organization is expected to identify the deficiency, correct it and prevent recurrence. Corrective action tickets are the evidence of that cycle. An assessor will usually check whether issues raised by monitoring, reviews or incidents reached an owner, were fixed within a reasonable time, and led to a change in policy or procedure where the root cause demanded it. A ticket that is opened and never closed is a finding in itself.
- Source and description: Each ticket records where the issue came from, such as an access review, a failed check or an incident.
- Owner and due date: A named owner and a target date show responsibility and timeliness.
- Root cause: Record why the control failed, so the fix addresses the cause rather than the symptom.
- Closure evidence: Link the ticket to the changed procedure, the completed fix or the retraining record.
- Ageing review: Periodically review open tickets so overdue items are escalated before the assessment period ends.
A gap looks like a repeated issue with no root cause change, or tickets closed with no evidence attached.
CC5.3 also expects policies and procedures to be reassessed, so the organization should be able to show that it reviews them at planned intervals and after significant change. A review log records the date, the reviewer, what was checked, and the outcome, including cases where a policy was confirmed without change. The log matters because an assessor cannot tell from a policy's content alone whether it is still in use or simply left untouched. Set the review cadence in the policy itself and keep the log separate from the policy text.
- Scheduled reviews: Each policy states its review frequency and the next due date.
- Trigger-based reviews: Changes in systems, regulation, incidents or organizational structure prompt an out-of-cycle review, which should be logged.
- Documented outcome: Record whether the policy was approved unchanged or revised, with a link to the new version.
- Coverage check: Confirm that every policy in scope appears in the log for the full period.
- Reviewer independence: Show that the reviewer has the knowledge and authority to judge the policy.
A gap looks like policies whose last review date falls outside the examination period or a log that only shows reviews done just before the audit.
How version history and role permissions support policy evidence
A wiki with version control gives an assessor a record of how a policy changed, but it does not make the policy effective. For CC5.3, the question is whether management's policies and procedures were reviewed, approved and followed. Page history is useful because it can show what changed, when and by whom, which helps answer whether policies were reassessed and updated over the examination period. XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control and lets users compare any two versions and roll back to an earlier one. Confirm in your own deployment that the history is retained long enough to cover your SOC 2 observation period and that rollbacks are logged rather than silently overwriting the record.
Role-based permissions answer a different question: who was able to change a policy. BookStack, licensed under MIT, derives user abilities from assigned roles and lets you override permissions per role at the shelf, book, chapter or page level. For a policy library, that means only the designated policy owners and approvers can edit or publish policy pages, while the rest of the organization has read access. Check that the permission model in your environment matches the approval decisions written into your policy, and test it by attempting an edit from a non-approver account. Ask your implementation partner to document the role matrix so the auditor can compare it against the policy owners you have named.
Neither product replaces the management decisions that CC5.3 expects: named owners, approval records, timely performance of procedures, corrective action when a procedure fails, and periodic reassessment of each policy. The wiki stores the policy and its history, while the evidence that controls actually operated, such as signed acknowledgments, review minutes and exception tickets, lives in your ticketing, HR or GRC systems. Before relying on either tool as evidence, confirm its current capabilities, supported versions and audit logging with the vendor, and read the AICPA 2017 Trust Services Criteria with revised points of focus (2022) so your control descriptions match what the auditor will test.
What meeting CC5.3 costs in money and effort
This table lists the cost components of putting CC5.3 policies and procedures into practice, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fees or durations are supplied for these items, so use it to structure your quote requests and internal budget, and confirm figures with your auditor and vendors.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Policy drafting and legal review | Internal staff or a consultant for drafting, and counsel if contract or privacy terms are involved | One-time to set up, then recurring at each annual review | Number of policies in scope, existing templates, and how many reviewers must sign off |
| Engineering and operations time for procedures | Internal engineers and operations staff write and run the procedures, with consultant help if requested | One-time to write, recurring while procedures run | Number of processes, how much is already automated, and how many teams perform the work |
| Evidence upkeep | Control owners and the team that stores records | Recurring throughout the observation period | Whether approvals, reviews and tickets are captured automatically or collected by hand |
| Training on policies | Internal security or HR staff, or a training provider | Recurring at onboarding and at scheduled refreshers | Headcount, staff turnover, and whether training is delivered with existing tools |
| External review or consulting | Consultant or fractional security lead, paid by the hour or under a fixed-scope agreement | Usually one-time readiness work, with optional recurring support | Internal maturity, the written scope agreed before work starts, and how many policies need rewriting |
| Auditor sampling effort | The CPA firm, billed under its engagement letter | Recurring at each examination period | Sample sizes the auditor selects, population size, and how quickly staff can produce requested records |
| Open-source software licenses | No license fee for the open-source platforms that host policy, approval and ticket records | Not applicable for license spend | Hosting, administration and support costs still apply, and commercial support is a separate purchase if chosen |
Questions buyers ask about CC5.3 policies and procedures
How much effort does CC5.3 take to meet?
The effort depends on how many control activities the policies must cover, how many systems and teams carry them out, and how much evidence already exists. CC5.3 itself restates COSO Principle 12: the organization deploys control activities through policies that set expectations and procedures that carry them out. The work splits into two parts: writing and approving policies, and making sure each procedure is performed and recorded. The second part is usually the larger effort, because it recurs for every period the auditor covers. Ask any provider to break its quote into policy drafting, procedure design, rollout to staff, and evidence collection across the observation period.
Can a small team handle CC5.3 without outside help?
A small team can usually write its own policies, provided someone owns each one and has time to run the procedures. The organization owns its controls, so the policies must reflect how the business actually operates, and staff must follow them. Outside help is most useful for reviewing whether policies match the system description, for designing procedures that leave usable records, and for checking gaps before the auditor arrives. Be clear about roles: an implementation partner can prepare documents and evidence, but only an independent CPA firm issues the SOC 2 report.
How long does policy and procedure work take?
The timeline depends on how many policies already exist, how quickly leadership approves them, and whether procedures are already running. Policy drafting can move quickly when a team reuses existing material, but approval and rollout take longer, because owners need to accept responsibility and staff need to be trained. Procedures must then operate for a period before a Type 2 examination can test them. No duration is set by the criteria, so confirm the expected schedule with your CPA firm and your internal owners in writing before work starts.
What will the auditor sample for CC5.3?
For a Type 2 examination, the auditor typically selects samples of policy reviews, procedure executions, training completions, corrective actions and reassessment records, then checks that each was performed on time by a competent person with clear accountability. The auditor also looks for evidence that the policy was approved, communicated and reviewed on a defined cycle. Sample sizes and selection methods are set by the auditor, so ask your CPA firm to explain its sampling approach during planning. Keep dated records that show who did what and when, because missing records are a common source of exceptions.
Can a consultant write our policies for us?
A consultant can draft policies and procedures, but the organization must adopt them, assign owners and run the procedures. Policies that describe practices the company does not follow create exceptions, so drafts should be reviewed against real workflows. Ask the consultant what it will deliver, who approves each document, and whether it will help you collect evidence after rollout. The same firm should not be asked to issue the report, because only an independent auditor can do that.
Do policies alone pass a SOC 2 examination?
No. Policies set expectations, but the auditor tests whether procedures were carried out and whether people with the right competence performed them on time. A policy that nobody follows, or that has no records behind it, will generate exceptions in a Type 2 report. Corrective action matters too: when a procedure fails, the organization should record the cause, the fix and the reassessment of the policy. Treat each policy as a commitment that must leave evidence every time it runs.
Which CC5.3 points of focus should we check first?
Start with the points of focus that ask whether management's directives are supported by policies and procedures, and whether someone is responsible and accountable for carrying them out. Then check timely performance, competent personnel, corrective action and periodic reassessment. The points of focus are characteristics that help design and evaluate controls, not separate requirements, so you do not need to address every one. Use the AICPA 2017 Trust Services Criteria to read the exact wording, and confirm your interpretation with your CPA firm.
Who owns CC5.3 and what an implementation partner can take on
Your organization owns CC5.3. Management decides which policies set expectations for security, availability and the other in-scope categories, approves them, and assigns a named owner to each control activity. Staff who run daily procedures, such as access reviews, change approvals and incident follow-up, perform the work and keep the records that show it happened. Management also remains accountable for the corrective action when a control fails and for scheduling the periodic review that keeps policies current with how the system actually runs.
- Policy approval: Leadership reviews and approves each policy and records the approval date and approver.
- Named ownership: Every procedure has an owner who is accountable for timely performance, not just a team name.
- Competent staff: Management decides what training and experience each role needs and confirms people meet it.
- Corrective action: Owners log deviations, decide the fix and track it to closure.
- Periodic reassessment: Management sets the review cycle and reviews policies after material changes to the system.
Check that each policy has a named owner, an approval record and a review date, and that the people in those roles can explain their own procedure without the partner in the room.
An implementation partner such as DeployOpen can help prepare the procedures, workflows and systems that carry out your policies. This work covers drafting procedure documents for management to review, configuring self-hosted tools so approvals, reviews and corrective actions leave a record, and setting up evidence collection so the auditor can see what was performed and when. The partner does not decide your risk appetite, approve your policies or sign off on whether a control operates. Those remain with your management.
- Procedure drafts: Partners prepare step-by-step procedures for management to adopt, adapt or reject.
- Workflow configuration: Ticketing, wiki and access tools are set up so ownership, approvals and deviations are recorded in the system.
- Evidence design: Partners define what each control produces, where it is stored and how it is retained.
- Corrective action tracking: Issue trackers and documented remediation steps make the path from finding to closure visible.
- Review scheduling support: Partners help build a calendar of policy reviews and reminders, which management then owns.
When you request a quote, ask for the written scope to list each procedure and evidence item, the deliverables, and which tasks stay with your staff after handover.
Only an independent CPA firm can perform a SOC 2 examination and issue the report. The service auditor tests whether your policies and procedures are designed appropriately and, for a Type 2 report, whether they operated effectively over the period. Under AT-C section 205, the auditor also obtains written representations from management, so management must stand behind the description and the controls. The auditor cannot write your policies or perform your procedures, because doing so would impair the independence the examination depends on.
- Design testing: The auditor checks whether each policy addresses its control objective and whether procedures match it.
- Operating testing: For Type 2, the auditor samples performed procedures across the observation period and examines the records.
- Evidence requests: The auditor asks for approvals, review records, training records and corrective action logs.
- Exceptions: Missed reviews or late corrective action can appear as exceptions in the report.
- Representation letter: Management signs a letter confirming its description and assertions.
Before engaging a CPA firm, confirm in its engagement letter which parts of the work it will perform and which it expects you to prepare.
Where CC5.3 implementations usually fall short
CC5.3 asks whether policies set clear expectations and whether procedures carry them out in practice. Most weak implementations fail on the gap between a written policy and the operating record behind it. The cards below pair each common gap with a step that closes it before the auditor's sample is drawn.
Policies without named owners
A policy that belongs to no one is rarely reviewed, enforced or updated. Auditors looking at CC5.3 check whether each policy names the role responsible for keeping it current and for performing the procedures under it. Assign one accountable owner per policy and record that owner in the policy header and in the document system. Confirm the owner can name the procedures they oversee.
Procedures that state intent, not frequency
Many procedures say that access is reviewed or backups are tested without saying how often, by whom or with what output. An auditor cannot test timely performance against a procedure with no timing. Write each procedure with a defined frequency, a named performer and a required record, such as a quarterly access review signed off in the ticketing system.
No record of corrective action
When a control fails, such as a missed patch window or an unreviewed leaver, CC5.3 expects the organization to act and to show that it did. Teams often fix the problem without writing down the root cause or the follow-up. Keep an exception log that records the failure, the corrective action taken and its closing date, and link each entry to the control it affected.
Stale policies and procedures
Policies written for the first audit often describe tools, teams or systems the organization no longer uses. A policy that contradicts current practice is a finding even when the control itself works. Set a scheduled reassessment date for every policy and record each review, including reviews that end with no change. Compare the text against the current architecture before each cycle.
Staff who have not been shown the procedure
A procedure only operates if the people who perform it know it exists and have the competence to follow it. CC5.3 looks for responsibility and accountability that reach the people doing the work. Keep a training acknowledgment for each procedure tied to the role that performs it, and refresh it when the procedure changes. New joiners should receive the relevant procedures during onboarding.
Versions that cannot be traced
When an edited policy overwrites the old text, the organization cannot show what was in force on a given date. Auditors sampling across a period need the version that applied at each point. Keep policies in a system that records every change, who made it and when, and that allows earlier versions to be restored. Wiki platforms such as XWiki and BookStack support this kind of history, but confirm the retention settings in your own environment.
How DeployOpen prepares CC5.3 evidence
This sequence turns a written policy and procedure set into self-hosted, owned and dated records that the organization's auditor can test. DeployOpen prepares the systems and evidence, while the organization owns its controls and an independent CPA firm issues any report.
Agree the scope in writing
DeployOpen and the client agree in writing which systems, policies, procedures and trust services criteria the work covers, along with deliverables and timelines. The client names an accountable owner for each policy and each procedure in scope. The step closes when the signed scope lists every policy, its owner and the platforms that will hold its records, so the work has a defined boundary before any build starts.
Map policies to the control activities they support
The client's team, with DeployOpen as a facilitator, traces each policy to the control activity it sets an expectation for and to the procedure that carries it out. The team records who performs each procedure, how often, and what triggers it. The output is a control matrix entry for every CC5.3 expectation, reviewed by the client. The step closes when no policy in scope lacks an owner, a trigger or a named performer.
Deploy a self-hosted documentation system
DeployOpen installs and configures a self-hosted wiki or documentation platform inside the client's own cloud account, data center or private network. Access is granted through roles that match the ownership map, so only assigned users can approve or edit each policy. The system keeps version history so that changes are traceable. The step closes when the client confirms that the platform runs in its environment and that role assignments match the approved matrix.
Configure version control and approval records
DeployOpen sets up the platform so each policy change records what changed, when and by whom, and so earlier versions can be compared and restored. The client defines who reviews and approves updates before they take effect. Procedures that run in tools, such as ticketing or deployment pipelines, are linked to the documents that govern them. The step closes when a test change shows the author, timestamp, approver and prior version in the record.
Build procedure evidence into operating tools
DeployOpen helps the client configure the operating tools that carry out procedures, such as ticket queues for corrective actions, scheduled reviews, and training completion tracking. Each tool keeps timestamps and owner fields so performance can be shown. Where a procedure cannot be automated, the client defines a manual record with a named performer. The step closes when a sample procedure can be traced from policy to a dated record of its performance.
Establish corrective action and reassessment cycles
The client and DeployOpen define how a missed or failed procedure is logged, escalated and corrected, and how policies are reassessed at set intervals and after significant change. The reassessment schedule and its owner are written into the policy set itself. The step closes when a documented test of a corrective action and a scheduled policy review both produce records the auditor can request.
Package evidence for the independent auditor
DeployOpen assembles an evidence index that maps each control activity to its policy, procedure record and system log, and organizes exports so the client can provide them to its CPA firm. DeployOpen does not issue reports, attestations or opinions, and it does not evaluate whether the controls meet the criteria. The CPA firm performs its own testing, and the client's management provides the written representations. The step closes when the client reviews the index and confirms it matches the controls it operates.
