How a cybersecurity incident affects ICFR and SOX reporting
A cybersecurity incident does not automatically change internal control over financial reporting (ICFR) or create a material weakness. It does require management to evaluate whether IT general controls (ITGCs), or the data and processing behind financial controls, were affected. That evaluation starts the day the incident is known, not at quarter end. The outcome depends on which systems were touched, which key controls relied on them, and whether the evidence needed to test those controls still exists. Under PCAOB AS 2110, the IT risks to ICFR include potential loss of data or inability to access data, and unauthorized access that could lead to destruction of data, improper changes, or recording of unauthorized or non-existent transactions. A ransomware event on a general ledger host and a compromised workstation with no finance access call for very different responses.
Start by mapping the affected assets against your SOX scope. Ask which financially significant applications, databases, infrastructure components and interfaces were in the attacker's path or lost availability, and which key controls depend on them. Then test each ITGC area that the incident could have touched: access to programs and data (were privileged or service accounts misused?), program changes (were any configurations or code altered outside approved change records?), and computer operations (were batch jobs, backups or restores disrupted?). Where a control did not operate as designed, SEC guidance in Release 33-8810 says the deficiency must be evaluated to determine whether it is a material weakness. Document the analysis as it happens, because the external auditor will ask how you reached each conclusion.
Evidence is what usually decides the outcome. Confirm which logs, change tickets, reconciliations and backup records survived, and whether they are complete for the period the attacker could have been active. If logs were lost, the question becomes whether compensating controls, such as independent reconciliations of affected ledgers, can show that the financial data was accurate. Ask your incident response team and forensic firm for written findings that state scope and timing, and ask your external auditor early how they expect to receive them. Section 302 certifying officers must also report significant deficiencies and material weaknesses to the auditors and audit committee, so the audit committee should see the evaluation before the next certification. Confirm the current status of these items with your auditor and counsel, since the answers depend on your facts.
What to do in the first days of an ICFR assessment after an incident
The first days after a breach or ransomware event should establish which financial systems were touched, which ITGCs protect them, and who has been informed, so that management can document a defensible initial impact view before deeper testing begins.
Contain the event and preserve evidence
Before any SOX analysis, the security and IT teams contain the incident and preserve logs, images, tickets and access records so they can be used later. Finance and internal audit should be told that a SOX assessment is starting, but they do not need to wait for forensic conclusions to begin. The output is a preserved evidence register with a named custodian for each source, which becomes the foundation for every later step.
Identify financially significant systems touched
Map the incident's known scope against the company's list of financially significant applications, databases, interfaces and infrastructure. Include systems that were not compromised directly but share credentials, networks, identity providers or administrative tooling with affected assets. The output is an affected-systems list that states, for each system, whether it was accessed, altered, made unavailable or only exposed, along with the date range still under investigation.
Determine whether data or processing was affected
For each system on the list, the finance, IT and security leads establish whether data was viewed, changed, destroyed or made inaccessible, and whether any transactions were recorded or altered without authorization. PCAOB AS 2110 treats unauthorized access to data, potential loss of data and inability to access data as IT risks to internal control over financial reporting, so each of these outcomes should be tested explicitly. The output is a data-and-processing impact note tied to each affected system.
Identify the ITGCs that protect affected systems
For each affected system, the SOX team identifies which ITGCs support the automated controls and reports that financial reporting relies on. Access to programs and data, program changes and computer operations are the areas most often involved in a security event, so they are reviewed first. The output is a mapping of each affected system to the specific access, change and operations controls that protect it, with the control owners named.
Notify the external auditor and audit committee
Management informs the external auditor and the audit committee of the incident and its known effect on financial systems, following the company's audit committee charter and the engagement arrangements with the auditor. Section 302 certifying officers must also disclose significant deficiencies, material weaknesses and fraud involving key control personnel to the auditors and audit committee, so the notification should be recorded against that obligation. The output is a dated communication record showing who was told, what was shared and what follow-up was agreed.
Document the control-by-control initial impact assessment
Management writes a memo that walks through each ITGC identified in step four and states whether the control is believed to have operated effectively, failed, or cannot yet be concluded on. Where a control may have failed, the memo records the financial reporting risk it supports and whether a compensating control exists. The output is a control-by-control impact memo, marked as preliminary, with a list of open questions and the owner responsible for each.
Evaluate deficiencies and set the next testing plan
Any control found not operating effectively is treated as a deficiency that must be evaluated for severity, consistent with SEC Release 33-8810, and the evaluation is not complete until management decides whether it could be a material weakness. The team then sets a testing plan for the open questions, covering what evidence will be collected, which period is covered and who will perform the work. The output is a deficiency log entry for each finding and an agreed testing plan reviewed with the external auditor.
Did the ITGCs fail? Evaluating impact by control area
Access controls are usually the first ITGC area a breach tests. An intruder who obtains valid credentials, escalates privileges or reaches a database holding ledger data raises the question of whether access to financially significant applications and data was limited to authorized people. Under PCAOB AS 2110, unauthorized access to data is named as an IT risk to internal control over financial reporting, because it may lead to destruction of data, improper changes or the recording of unauthorized or non-existent transactions. Management should therefore reconstruct who had access, when, and whether any access was used.
- Account population: Export the user and privileged account lists for the affected systems as of the incident window and compare them with approved access records.
- Authentication logs: Preserve directory, VPN, database and application logs that show the logons and privilege changes during the intrusion.
- Access reviews: Show whether periodic reviews of privileged and financially significant access ran before the event and what they found.
- Use versus entitlement: Determine whether any unauthorized account actually posted, altered or viewed financial data.
- Terminations and service accounts: Check whether accounts of departed staff or unmanaged service accounts were involved.
Confirm with your auditor which of these populations they will sample and whether a failed access review is treated as a control failure in its own right.
Program change controls test whether changes to financially significant applications, configurations and infrastructure are authorized, tested and approved before reaching production. Ransomware and intrusions often involve emergency changes: disabled logging, modified scheduled jobs, altered interfaces or new administrative tools pushed outside the normal workflow. Each unapproved change is an exposure, because a change that bypasses approval can alter how transactions are processed. Management should identify every change made during the intrusion period and test whether it followed the change process, including retrospective approval for emergency work.
- Change inventory: Build a list of all production changes in the window, including those made by responders during containment.
- Emergency change records: Show the justification, approver and post-implementation review for each emergency change.
- Configuration baselines: Compare current configurations of financial applications and their security settings with the last approved baseline.
- Recovery changes: Document rebuilds and patches applied during recovery as changes, with testing evidence.
- Segregation of duties: Confirm that the people who made changes were not the only approvers.
Ask whether responder actions will be treated as changes under your policy, because undocumented containment work is a common source of audit findings.
Program development controls cover acquiring, building and implementing new financially significant systems, including testing, data conversion and go-live approval. A breach affects this area when an incident occurs during a system implementation, when an attacker alters a project environment, or when recovery requires a replacement system to be built quickly. Management should check whether any new system or major upgrade went live during or after the incident without the usual testing and approval, and whether data migrated during recovery was reconciled to source records. The question for the auditor is whether a rushed build still produced complete and accurate financial data.
- Project inventory: List implementations, upgrades and data migrations active during the incident window.
- Go-live approvals: Confirm that each system placed into production during recovery had documented testing and sign-off.
- Data conversion reconciliations: Show that migrated balances and transaction counts tie to source systems.
- Development environment access: Check whether intruders reached build pipelines, project repositories or test data containing production extracts.
- Accelerated releases: Identify any expedited releases and the compensating review that applied.
Confirm with management and your auditor whether a recovery build is a new implementation or a restoration of an existing system, since the evidence expected for each differs.
Computer operations controls keep financially significant processing running completely and accurately. This area includes job scheduling, backups and recovery, incident handling and oversight of IT service providers. Ransomware most directly tests this area because it can encrypt data, stop batch jobs and corrupt reports. The auditor will ask whether data integrity was restored, whether backups were complete and uncorrupted, and whether processing errors during the outage were identified and corrected. Management should show that restored data was validated against records before it supported financial reporting.
- Backup integrity: Evidence that backups used for restoration were not encrypted or altered by the attacker and were tested before use.
- Restoration validation: Reconciliations of restored ledgers, subledgers and key reports to pre-incident control totals.
- Batch job status: Logs showing which scheduled jobs failed, were rerun or were skipped during the outage.
- Incident records: A timeline of detection, containment, eradication and recovery with decisions and approvals.
- Service provider reports: Where a managed provider ran operations, its incident reports and the organization's review of them.
Confirm the restoration point and the reconciliation method with your auditor before the first restore is validated, since changing the method later weakens the evidence.
SEC guidance in Release 33-8810 says that if management determines a control is not operating effectively, a deficiency exists that must be evaluated to determine whether it is a material weakness. For ITGCs, the test is whether the failure could allow a misstatement in an IT-dependent control to go undetected. A failed access review or an unapproved change does not automatically mean the financial statements are wrong, but it does require evaluation of whether compensating controls, such as management review of account balances, operated effectively. Under Rule 13a-15(c), this evaluation is part of the annual assessment, so documentation of the analysis matters as much as the failure itself.
- Impact on automated controls: Identify which application controls rely on the failed ITGC and whether they were relied upon during the period.
- Compensating controls: Document any manual review that could detect a misstatement and show that it operated.
- Likelihood and magnitude: Record the reasoning behind the severity conclusion for each deficiency.
- Aggregation: Consider whether several small ITGC failures together create a material weakness.
- Audit committee communication: Track the deficiencies and their evaluation for disclosure decisions.
Ask your auditor for their view on the severity of each deficiency before you finalize the evaluation, because the conclusion must be supportable to both management and the auditor.
When a breach changes financial data or transaction processing
The question that matters for ICFR is not whether an incident touched systems, but whether it changed the completeness, accuracy or existence of recorded transactions. An intrusion that only exposes personal data or disrupts a non-financial application may leave the ledger untouched. A ransomware event that encrypts a general ledger database, a unauthorized user who edits invoice amounts, or an attacker who posts journal entries that no one approved can change the financial statements directly. PCAOB AS 2110 (paragraph B4) names three IT risks that map to this: potential loss of data or inability to access data, unauthorized access that could lead to destruction of data, and improper changes or unauthorized or non-existent transactions being recorded. Management should walk each of these through the financially significant applications and interfaces in scope and record what the incident could have done to each one, not only what it did.
Once systems are restored, management needs to show that the reports and data feeding key controls are still reliable. Reports produced by the affected system, such as aged receivables listings, reconciliation extracts or user access reports, should be re-validated against source data, including their logic and parameters, before anyone relies on them in a review control. Confirm with your auditor how they expect this re-performance to be documented and whether restored data sets are subject to the same completeness and accuracy checks as the original. Also confirm which backups were used, whether they predate the intrusion, and whether any transactions processed between the last clean backup and the outage were reconstructed from logs, interfaces or source documents.
Do not assume the breach is contained because the systems are running again. Ask the team to record the date of the earliest suspicious activity, the period of possible data alteration, and every journal entry, master data change and privileged action in that window, then compare them with the authorization evidence that exists. Where an unauthorized or unexplained transaction is found, treat it as a potential misstatement to be evaluated under the ICFR deficiency process, not as a security ticket alone. Your auditor will ask for this analysis early, so agree on its scope, owner and documentation standard before the investigation closes.
How quarterly change disclosure and Section 302 certifications respond
Once an incident is under way, the quarterly report and the officer certifications put it on the record. Each statement below has a named owner and needs evidence that the controls and the incident response actually held up.
Changes in ICFR during the quarter
Item 308(c) of Regulation S-K requires disclosure of changes in internal control over financial reporting during the last fiscal quarter that materially affected, or are reasonably likely to materially affect, ICFR. Management owns the judgment. A ransomware recovery that rebuilds an access system or an emergency change to a financial application can meet that test. Check that every incident-driven change is logged, classified and reviewed by the disclosure committee, with its approval records kept.
Officer statement on internal controls
Under Section 302, the certifying officers state that they are responsible for establishing and maintaining internal controls. This statement covers the incident too: the officers are attesting that controls over financial reporting remain in place while systems are restored. Ask the certifying officers which incident facts they relied on, and confirm that the sub-certification chain from IT and finance leaders is documented before signing.
Evaluation within 90 days
The certifying officers state that they evaluated internal controls within 90 days before the report. An incident that closes inside that window still needs its own evaluation of the controls that failed or were bypassed. Keep a dated evaluation memo that records which controls were tested, when, and by whom. A memo written only from the incident timeline, without test results, is weak evidence.
Deficiencies and fraud reported to auditors
The officers disclose to the auditors and the audit committee any significant deficiencies, material weaknesses, and fraud involving management or employees with a significant role in internal control. A breach that bypassed access controls or altered financial data can meet this threshold. Confirm that the deficiency log captures incident-related failures, and that each entry shows the auditor and audit committee communication date.
Significant changes reported to auditors
Section 302 also requires officers to report significant changes in internal controls, including corrective actions taken after a significant deficiency or material weakness. Remediation of an incident, such as new privileged access rules or restored backup procedures, belongs in this report. Check that each corrective action has a clear start date, a control owner and test evidence showing it operates.
Why the Form 8-K materiality decision runs separately from ICFR
The Form 8-K decision under Item 1.05 turns on the materiality of the cybersecurity incident itself, not on whether an internal control failed. A company can have a serious breach with no ICFR deficiency, or a control failure with no incident that requires a Form 8-K. Management therefore needs two separate assessments that draw on the same facts. The Item 1.05 disclosure is generally due within four business days after the registrant determines the incident is material, and it must describe the nature, scope, timing and material impact of the incident. The SEC adopted these rules on July 26, 2023 (SEC press release 2023-139). The clock starts at the materiality determination, so the documented date and reasoning of that determination become part of the record that counsel, the audit committee and the external auditor will later examine.
The two conclusions can differ for good reasons. The ICFR evaluation asks whether the IT general controls that support financial reporting operated effectively, and whether any deficiency could lead to a material misstatement of the financial statements. The Form 8-K question asks whether a reasonable investor would consider the incident's effect on the company significant. An attacker may read data without altering any financial record, which can be material for disclosure yet leave ICFR unaffected. The reverse also happens: a change to a journal entry process may be a significant ICFR deficiency that never touches the incident threshold. Teams should write down both conclusions, the facts each relied on and the date each was reached, so that a difference between them can be explained.
Disclosure counsel makes the Form 8-K materiality decision, with management, the audit committee and the security function providing facts. Your job is to make sure the inputs are ready: the incident timeline, systems and data affected, whether financially significant applications or access paths were involved, and which controls were relied on during response. Confirm with counsel which internal groups must be convened and how quickly, because the four-business-day window is short. For filing mechanics and the relationship to your existing ITGC program, read the sibling topic on SEC cybersecurity disclosure rules and SOX ITGC programs.
Where incident response and SOX reporting usually collide
Most ICFR problems after a breach do not come from the attack itself. They come from containment steps that destroy evidence, emergency changes without approval, and unclear ownership between security, IT and finance. Each card below names one collision point and the step that avoids it.
Treating the incident as a material weakness
An incident does not automatically mean a control failed. Management must first ask whether the affected IT general controls were operating, whether any financially significant application or data was touched, and whether a key control relied on the compromised system. Document that analysis before drawing a conclusion. If a control is found not operating effectively, SEC guidance says that deficiency must still be evaluated to decide whether it is a material weakness, so the record of that evaluation matters as much as the outcome.
Losing logs during containment
Containment often involves rebuilding hosts, rotating credentials or wiping compromised systems, which can delete the access and change logs auditors need to test the period. Before containment starts, preserve authentication logs, privileged activity records and change tickets for the affected systems. Confirm with the incident team and your auditor which copies are the system of record. Without those logs, management may be unable to show that access controls operated during the window in question.
Emergency changes without approval
Responders frequently patch, reconfigure firewalls or disable accounts outside the normal change process. Those changes can reach production without the authorization and testing evidence that the program change controls require. Set up an emergency change path in advance that still records who approved the action, what changed and when it was reviewed after the fact. Retroactive tickets written weeks later are easy for auditors to identify and tend to weaken the evidence.
Restored data that cannot be reconciled
When systems are restored from backup, finance may find balances, transaction counts or interface totals that no longer agree with the pre-incident records. A restore that cannot be reconciled raises questions about completeness and accuracy of processing, which are computer operations concerns. Record the backup point used, compare restored totals to independent control reports, and document every manual correction. Confirm the reconciliation method with finance and the external auditor before the restore, not after.
Unclear ownership across teams
Security leads the response, IT runs the systems, and finance owns the reporting conclusions, yet no single person may be accountable for the ICFR evaluation. Decisions about whether data was affected, whether a control failed and whether a disclosure is needed can then stall or be made without the right inputs. Assign a named owner for the SOX assessment inside the incident process, and define which roles provide each input and which role approves the conclusion.
Late notice to the auditor
External auditors plan their testing early and rely on management to report significant incidents, control changes and suspected fraud. If the auditor learns about a breach from a public filing or a late update, the relationship and the timing of testing can both suffer. Agree in advance how and when incidents are reported to the audit team, including the first notice, the working updates and the closure summary. Route Section 302 certification discussions through the same channel so officers and auditors hear about changes at the same time.
Who owns the ICFR evaluation, the disclosure and the audit
Management owns the internal control over financial reporting. That includes evaluating whether an incident or a failed IT general control created a deficiency, deciding how severe it is, and documenting that judgment as of fiscal year end. The principal executive and principal financial officers sign the Section 302 certifications, and the Form 8-K Item 1.05 materiality determination is made by the company with its securities counsel and disclosure committee, not by the security team alone.
- ICFR evaluation: Management assesses whether affected IT general controls still operated effectively and whether any resulting deficiency is a material weakness under the SEC's definitions.
- Certifications: Officers certify internal control responsibilities and disclose significant deficiencies, material weaknesses and fraud involving key control personnel to the auditors and audit committee.
- Quarterly change disclosure: Finance determines whether any change in ICFR during the quarter materially affected, or is reasonably likely to affect, internal control.
- Form 8-K decision: Counsel and the disclosure committee judge materiality and the four-business-day clock once the company determines an incident is material.
Confirm with your counsel and auditor which committee approves the materiality assessment and how it is recorded.
The security and IT team produces the facts management needs. They establish what systems were accessed, whether data was altered or made unavailable, which financially significant applications and databases were in the path, and how the response changed access, change management or backup procedures. Their work feeds the ICFR judgment but does not replace it.
- Scoping the incident: Identify affected systems, accounts, data sets and the period of unauthorized activity, then map them to in-scope applications and reports.
- Control status: Report which access, change and operations controls failed, were bypassed during response, or ran under emergency change procedures.
- Data integrity: Document whether financial data was altered, deleted or made unavailable, and whether processing completed accurately.
- Recovery records: Keep restoration logs, approvals for emergency changes and post-incident access reviews with timestamps.
Confirm that incident tickets, change records and access logs are preserved under the company's retention rules before anyone closes the response.
An implementation partner such as DeployOpen can help the organization prepare its systems, logs, restoration evidence and documentation. The partner works inside the client's own infrastructure and under a written scope. It does not decide whether a deficiency exists, sign certifications, make the disclosure decision or issue any report.
- System preparation: Configure logging, access reviews and change workflows on self-hosted platforms so that the evidence exists before an assessor asks for it.
- Restoration evidence: Test and document backup restoration so that management can show data was recoverable and complete.
- Documentation: Write runbooks and control descriptions that match how the platform actually operates after an incident.
- Walkthrough support: Help the internal team explain system behavior to the auditor, while management answers for the conclusions.
Ask any partner to put in writing which artifacts it will prepare and confirm that it will not sign or attest to control conclusions.
For accelerated and large accelerated filers that are not emerging growth companies, the external auditor performs the ICFR attestation under PCAOB AS 2201 in addition to management's own assessment required by Section 404. The auditor also assesses IT risks under AS 2110, including potential loss of data and unauthorized access to data, as part of its risk assessment. The auditor is independent of management and is the only party that issues the attestation report.
- Attestation report: Only the independent auditor issues the attestation on the effectiveness of ICFR, where Section 404(b) applies.
- Independent testing: The auditor tests controls itself and cannot rely solely on evidence prepared by management or a partner without its own procedures.
- Communications: The auditor communicates significant deficiencies and material weaknesses to management and the audit committee.
- Independence limits: Auditor independence rules restrict the auditor from designing or operating the controls it audits.
Confirm with your auditor which evidence it will accept, its sampling approach and whether an incident changes its scope before year end.
Questions finance and security leaders ask after an incident
Does every cybersecurity breach create a material weakness?
No. A breach does not automatically create a material weakness in internal control over financial reporting. Management first asks whether an IT general control or an IT-dependent control failed, and if one did, whether the failure is a deficiency, a significant deficiency or a material weakness. SEC guidance in Release 33-8810 says that when a control is not operating effectively, a deficiency exists that must be evaluated to determine whether it is a material weakness. The attacker's access alone does not answer that question. What matters is whether the access could have changed financial data or processing, whether the affected systems feed financial statements, and whether compensating controls would have detected a misstatement in time. Management owns this judgment, and the external auditor will test it.
Do we have to file Form 8-K within four business days of a breach?
Only if the incident is material. Form 8-K Item 1.05 requires disclosure generally within four business days after the registrant determines that a cybersecurity incident is material, not after the incident is discovered. The SEC's July 26, 2023 press release 2023-139 describes the content as the incident's nature, scope, timing and material impact. The materiality decision is separate from the ICFR evaluation. An incident can be material for disclosure reasons without creating a material weakness, and the reverse can also happen. Companies usually document the materiality analysis with legal counsel, the disclosure committee and the audit committee, and they record when the determination was made because that date starts the clock.
How do we know whether an ITGC actually failed?
Start by tracing the incident back to the controls it touched. Identify which financially significant applications, databases and infrastructure the attacker could reach, then check the access, change management and computer operations controls over them. Look for evidence of unauthorized access, privilege escalation, unapproved changes to code or configuration, disabled logging, or backups that could not restore data. PCAOB AS 2110 lists unauthorized access to data, which might lead to destruction of data, improper changes or unauthorized transactions, as an IT risk to ICFR. Pull the logs, change records and access reviews for the relevant period and compare them with the control design. A control that existed but was bypassed is still a design or operating question to document, so the team should record what the logs show rather than what people remember.
Do we need an outside firm to evaluate the impact on ICFR?
Not necessarily, but most companies bring in outside help for part of the work. Management owns the ICFR evaluation and the conclusion, and only the external auditor issues the attestation under PCAOB AS 2201 when the company is subject to it. Consultants can support forensic log review, control testing, documentation and the deficiency analysis, while security specialists can establish what the attacker accessed. Be clear about roles in the engagement letter. An implementation partner can prepare systems, logs and evidence for review, but it does not issue audit conclusions. Ask any firm to confirm in writing which parts of the evaluation it performs and which remain with management and the auditor, and whether its independence rules allow it to support the testing you need.
What does the evaluation need from our finance and security teams?
The work needs a joint team with clear owners. Security leads establish the timeline, affected systems, attacker actions and containment steps. IT operations provides change tickets, access reviews, configuration history and backup status. Finance identifies which reports, balances and processing flows depended on the affected systems. Internal audit or the SOX program office tracks which key controls were in place and tests them. Legal and the disclosure committee handle the Form 8-K materiality analysis. The team also needs a single evidence log with dates, owners and the system of record for each item. Without that log, it becomes hard to show the auditor what happened, and the quarterly change disclosure under Item 308(c) may be difficult to support.
Can we reuse existing ITGC evidence for the incident review?
Often yes, for the baseline. Access reviews, change approval records, backup restore tests, job monitoring reports and prior test results show what the control looked like before the event, which helps establish whether it was designed and operating effectively. The incident itself creates new evidence that must be collected separately, including logs, forensic images, containment decisions and remediation tickets. Check whether the retained logs cover the full dwell time, because the attacker may have been present well before detection. Also confirm that prior evidence was produced from systems of record and not from spreadsheets that someone updated after the fact, since auditors give more weight to evidence generated directly by the system.
How DeployOpen prepares evidence for an ICFR evaluation after an incident
DeployOpen can help your team assemble the technical evidence that management and the external auditor will ask for after a cybersecurity incident touches financial systems. As an implementation partner, DeployOpen plans, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Under a fixed-scope written agreement, that work can include building an inventory of affected systems, collecting log and change records for the period under review, and documenting restoration steps and their results. Those artifacts give the control owners a factual base for deciding whether IT general controls over access, program changes or computer operations failed, and which financial applications and data were touched.
Before any work starts, agree in writing on which systems, logs and time windows are in scope, and who owns each output. Confirm with your auditor which evidence formats they accept, how they want change tickets linked to affected applications, and whether they expect restoration records to show data integrity checks. Ask whether the platforms in scope can export audit logs with timestamps and user identities, and confirm retention periods with the people who own those logs. Do not assume a platform produces a given record until it has been tested in your environment.
DeployOpen does not issue audit reports, attestations or certifications. It does not decide whether an incident is material, whether a deficiency is a significant deficiency or material weakness, or whether ICFR is effective. Those conclusions belong to management, the audit committee and the independent auditor, and the Form 8-K materiality decision belongs to the registrant with its counsel. Outcomes are not guaranteed, because evidence quality depends on the state of your environment before the incident. Quotes follow from the written scope of work, and DeployOpen does not publish a price list.
