Summary
- Frontier disclosed in an SEC filing that it detected unauthorized access to its IT environment, shut down certain systems to contain the incident, and experienced operational disruption.
- The accountability issue is that telecom customers depend on service availability, billing support, account access, installation support, repair coordination, and reliable notice even while the operator is isolating systems.
- Frontier later faced customer-data notice and settlement context, showing that containment and restoration did not end the public-risk question.
- Telecom resilience guidance from CISA, FCC-related reliability structures, and NIST recovery guidance frame the incident as a critical-service continuity problem, not only a corporate IT event.
- A credible repair record should show which systems were isolated, what customer-facing services were affected, how support workarounds functioned, what personal data was accessed, what monitoring changed, and how future containment would preserve customer trust.
A telecom cyber incident reaches customers before the details do
Frontier's Form 8-K, filed with the SEC and available in the April 2024 filing, said the company detected unauthorized access to its IT environment, shut down certain systems as part of containment, believed a third party gained access to personally identifiable information, and experienced operational disruption. That filing is the central public record because it ties the incident to both cyber containment and customer-information risk.
For a telecom operator, those two facts sit close together. Customers may experience service problems, support delays, billing uncertainty, installation delays, repair scheduling gaps, account-access problems, or ambiguous notices before they understand what happened. Even if core network service remains available for many customers, the systems that surround service can still matter. A broadband account is not only a line. It is support, billing, authentication, repair, customer premises equipment, technician dispatch, and communication.
Cybersecurity Dive reported on the Frontier Communications cyberattack and operational disruption. MSSP Alert reported that systems were restored after the attack on Frontier Communications. These reports help situate the filing in operational terms. The public did not receive a full technical incident report. It received a company disclosure and subsequent reporting about disruption, restoration, and data exposure.
The accountability question begins with what customers could see. If a customer could not reach support, change account settings, schedule repair, or understand whether a notice was legitimate, the incident created practical risk even without a total service outage. Telecom providers are trusted because communications service is a dependency. When internal systems are isolated, the operator must preserve a customer-facing path that is reliable enough for ordinary people and small businesses.
This is not a demand for perfect availability during an intrusion. Containment may require shutting down systems quickly. The accountable demand is proof that the operator had a continuity plan for customer-impacting functions while containment was under way.
System isolation is a tradeoff that needs evidence
Frontier's filing said certain systems were shut down to contain the incident. That can be a responsible move. If unauthorized access is active, isolating systems may prevent further spread, data access, or attacker persistence. But system shutdown also creates tradeoffs. It can disrupt employees, support teams, billing systems, customer portals, installation scheduling, repair workflows, internal reporting, and partner integrations.
NIST's Computer Security Incident Handling Guide provides a lifecycle for preparation, detection, analysis, containment, eradication, and recovery. NIST's Guide for Cybersecurity Event Recovery emphasizes recovery planning and validation. Applied to Frontier, those guides frame isolation as one stage in a larger operating problem: contain without losing the ability to understand, communicate, and restore.
The evidence questions are practical. Which systems were isolated? Which customer-facing workflows were affected? Which backups or alternate channels supported support teams? How were technicians dispatched if normal systems were unavailable? How did billing exceptions get handled? How were enterprise customers updated? How did the company validate that restored systems were clean? How did it preserve forensic evidence while restoring operations?
Customers do not need every sensitive technical detail. They do need credible answers to their lived questions. Can I pay my bill safely? Can I report an outage? Will my installation be delayed? Is this support message real? Was my data accessed? Should I watch for fraud? If the company cannot answer those at least at a high level, containment has transferred uncertainty to customers.
System isolation also tests internal decision rights. Who can order a shutdown? Who approves bringing a system back? Who decides whether customer portals stay offline? Who coordinates legal, security, network operations, customer care, and communications? During an intrusion, those decisions cannot wait for normal hierarchy. They must be rehearsed.
Telecom continuity is public-service continuity
CISA identifies the communications sector as critical infrastructure. CISA's critical infrastructure resilience resource frames resilience as preparing for, withstanding, recovering from, and adapting to disruptions. Frontier's incident belongs in that context because broadband and telecom service support work, education, health, emergency communications, small-business operations, and public administration.
This does not mean every corporate IT incident at a telecom provider creates a nationwide communications emergency. It means the operator should manage cyber incidents with awareness that customer-facing continuity matters. The public may not distinguish between a core network issue, a billing-system issue, a customer-portal outage, and a support disruption. All affect trust in communications service.
The FCC's Network Outage Reporting System and the Communications Security, Reliability, and Interoperability Council provide regulatory and policy context for communications reliability. Those resources are not a specific finding about Frontier's incident, but they show that telecom reliability is a public policy concern. A cyber incident that affects customer operations should be evaluated through that resilience lens.
Small businesses are especially exposed. A local business may depend on Frontier service for payment terminals, phones, customer scheduling, remote work, and cloud applications. If support channels are disrupted, the business may have few alternatives. Residential customers may depend on broadband for work, school, medical portals, or caregiving. A telecom operator's continuity plan should therefore consider more than enterprise accounts and network cores.
Public-sector customers also matter. Schools, local agencies, emergency services, libraries, and community organizations often depend on commercial telecom providers. They may not be affected in the same way as residential users, but they need timely information if service or support is impaired. A public-service continuity mindset would segment communications by customer type and urgency.
Personal-information risk outlasts restoration
Frontier's SEC filing said the company believed the third party gained access to personally identifiable information. Later public settlement materials, including the Frontier data settlement site and a court complaint PDF, show that customer-data exposure remained part of the public record after systems were restored. A complaint is not a finding of fact, and a settlement site has its own legal purpose, but together they show that personal-data accountability extends beyond initial containment.
This distinction matters. A cyber incident can be operationally contained while privacy and fraud risk remain open. Customers may need notice, credit monitoring, fraud guidance, password resets, account reviews, or reassurance about what was not accessed. Restoration of internal systems does not answer whether data was taken, how it could be misused, or how long the risk lasts.
The FTC's Data Breach Response guide provides general guidance on notifying affected people and helping them reduce harm. In the Frontier context, the key is clarity: what data was involved, which customers were affected, when the access occurred, what the company did, what customers should do, and how to verify legitimate communications.
Telecom data can be sensitive in several ways. It may include names, addresses, account numbers, contact details, billing records, service locations, authentication information, or service history. A criminal can use such data to phish, impersonate support, attempt account takeover, redirect communications, or target households and businesses. Even if the exposed data is not the most sensitive category, the telecom relationship increases misuse potential.
The accountable repair should separate restoration metrics from privacy metrics. System uptime, customer portal restoration, and support availability are one set. Notice completion, data-scope confidence, fraud reports, customer questions, and litigation or settlement obligations are another. A mature incident report does not collapse them into a single "resolved" status.
Customer communication has to survive the outage
During a cyber incident, the communications provider has to communicate. That sounds obvious, but it is operationally difficult when internal systems are disrupted. Customer emails may be delayed. Website updates may require systems that are offline. Support agents may lack account context. Social media may fill with rumors. Enterprise account teams may have partial information. Scammers may imitate the company while customers are anxious.
The incident response plan should therefore include out-of-band communication. The company should know how to post verified updates, authenticate customer messages, brief support staff, coordinate with regulators, and reach critical customers if normal systems are down. Communications should be tiered: public status, customer support guidance, enterprise account notices, data-breach notices, and regulator communications may require different content.
The FBI's IC3 ransomware and cybercrime public service announcement is general, but it reinforces that customers and companies should report and manage cybercrime carefully. In a telecom incident, customers may receive suspicious calls or emails claiming to help with account restoration, billing, or refunds. The provider should tell customers what legitimate contact looks like.
Good communication is also honest about uncertainty. Early in an incident, the company may not know whether data was accessed, which systems are affected, or when full service will return. Saying "we are investigating" is acceptable if paired with what customers should do now and when the next update will come. Silence is worse because it lets customers and attackers invent the story.
Customer communication should also be accessible. Not every customer follows investor filings or cybersecurity news. Residential customers may need plain-language website updates. Small businesses may need operational advice. Enterprise customers may need account-team briefings. Public-sector customers may need continuity coordination. The same core facts should be adapted without contradiction.
Ransomware-style impact techniques clarify the risk model
The public record does not require us to classify Frontier's incident as a particular ransomware event, but general attack techniques help explain the risk model. MITRE ATT&CK describes Service Stop, Data Encrypted for Impact, and Exfiltration Over C2 Channel. These techniques are relevant because telecom incident response must consider system disruption, data theft, and attacker control paths together.
CISA's StopRansomware guide provides preparation and recovery guidance. Even if a particular incident involves data theft without encryption, the same resilience themes apply: backups, segmentation, identity controls, incident response, communication, recovery validation, and law-enforcement coordination. A telecom operator should be able to contain an intrusion without losing sight of customer continuity.
The risk model should include dependencies. Customer portals may rely on identity systems. Billing may rely on CRM and payment processors. Technician dispatch may rely on scheduling platforms. Support may rely on knowledge bases and authentication tools. Enterprise circuits may rely on separate network-management systems. Containment may affect some dependencies while leaving others intact. The response must know which functions matter most to customers.
It should also include attacker leverage. If attackers exfiltrated personal data, they may threaten leaks. If they disrupted support systems, they may create customer pressure. If they accessed internal communications, they may use stolen context. If they obtained credentials, they may return. The repair should therefore include credential rotation, access review, monitoring, segmentation, and customer fraud warnings, not only restoration.
Telecom operators are attractive targets because they sit close to identity, connectivity, and critical services. A breach can have reputational value for attackers even if direct network operations remain intact. That makes public clarity important. Customers need to know which part of the telecom environment was affected and which was not.
Investors, customers, and regulators need different evidence
Frontier's investor SEC filings page provides the formal investor-disclosure channel. Investors need to know material impact, operational disruption, costs, litigation, and risk controls. Customers need practical guidance. Regulators need compliance, notice, and reliability evidence. The incident response should produce evidence that can serve all three without forcing one audience's language onto another.
Investor disclosure may describe operational disruption and materiality. Customer notice should describe personal data and actions. Telecom reliability reporting may describe service impact. Internal board reporting should describe root causes, control changes, and residual risk. If these records diverge, trust suffers. If they align, the company can communicate with confidence.
The class-action and settlement context shows why evidence matters. Customers and plaintiffs may challenge whether notice was timely, whether data categories were clear, whether safeguards were reasonable, and whether remediation was adequate. Regulators may ask similar questions in a different form. A company that preserves logs, decisions, and customer-support metrics is better positioned to answer.
Evidence also protects against overclaiming. If the company says core network service was not materially affected, it should know which systems support that statement. If it says data exposure was limited, it should know how scope was determined. If it says systems are restored, it should know how restoration was validated. These statements are not public-relations flourishes. They are evidence claims.
For customers, the evidence should appear as plain confidence. The company does not need to publish every forensic detail, but it should avoid empty reassurance. "We restored affected systems and continue to monitor" is less useful than "customer service channels are operating, billing functions are available, data notices have been sent to affected customers, and customers can verify communications here." Specificity reduces uncertainty.
The repair standard is continuity with defensible boundaries
The strongest repair standard for Frontier is continuity with defensible boundaries. Continuity means customers can use service, get support, pay bills, schedule repairs, receive updates, and understand notices during and after containment. Defensible boundaries mean the company can explain what was affected, what was not affected, which data was accessed, which systems were isolated, and what controls changed. Both are necessary.
Continuity alone is not enough because data risk may remain. Data-scope clarity alone is not enough because customers need service and support. A telecom operator must hold both. That is the special accountability of communications infrastructure: it is both a business and a dependency.
The repair should be measured by operational and trust indicators. Operational indicators include system restoration, support availability, ticket backlogs, installation delays, outage reports, and enterprise-customer communication. Trust indicators include notice completion, customer fraud reports, complaint volumes, settlement or litigation obligations, support-script clarity, and verified improvements to access control and monitoring.
Future incident exercises should simulate system isolation. What happens if customer portals go offline? How do support agents verify customers without normal tools? How are technicians dispatched? How are public updates posted? How are data-breach notices sent if email systems are affected? How are enterprise and public-sector customers prioritized? The exercise should include customer-care and communications teams, not only security engineers.
The public lesson is not that Frontier failed every part of this test. The public record does not show enough to make such a claim. The lesson is that Frontier's incident revealed the shape of the test. A telecom cyber event is not closed when systems are turned back on. It is closed when service continuity, customer communication, data-risk notice, and control repair are all supported by evidence.
Residual unknowns and the accountable question
The public record does not disclose every technical detail of the Frontier incident. It does not show the full attacker path, every system isolated, the complete restoration sequence, the exact data fields accessed for every affected customer, the internal governance review, or every control change. It does show unauthorized access, containment through system shutdown, operational disruption, personal-information concern, later customer-data notice and settlement context, and telecom-resilience implications.
The accountable question is whether Frontier converted containment into trust-preserving continuity. That means knowing which customer functions were affected, keeping safe communication channels open, separating service-status from data-risk status, supporting affected people, and proving that restored systems were validated. It also means improving internal controls so a future intrusion can be contained with less customer uncertainty.
Customers do not need to understand SEC disclosure rules or telecom infrastructure to deserve clear answers. They need to know whether service works, whether support is real, whether data was exposed, what steps to take, and where to verify information. Investors and regulators need deeper evidence. The operator must serve all of those needs.
Frontier's incident should therefore be remembered as a telecom continuity accountability case. A communications provider's cyber response is part of the service it sells. When the provider isolates systems to defend itself, the public test is whether customers can still rely on the company to communicate, support, and protect them with clarity.
Billing and support are part of the service promise
Telecom providers sometimes separate network availability from customer operations. The fiber route may work while billing, account management, repair scheduling, or customer-care tools are impaired. From the customer's perspective, those functions are still part of service. A household that cannot reach support during a move, a small business that cannot resolve a billing issue, or an enterprise customer that cannot escalate a circuit problem experiences the incident as service degradation even if packets continue to flow.
That is why customer-care continuity should be part of telecom cyber exercises. The plan should identify which support functions can operate manually, which require secure read-only access, which can be deferred, and which are critical. It should define how to verify customers if normal identity tools are down. It should define how to capture tickets for later reconciliation. It should define how agents explain uncertainty without inventing facts. A support workaround that cannot be audited later may solve one problem and create another.
Billing continuity deserves special attention. Cyber incidents can interrupt autopay changes, credits, disputes, late-fee handling, refund processing, and account closure. Customers should not be penalized for company-side system isolation. The company should have a policy for fees, collections, service suspension, and dispute timing during incident-related disruption. If customers are told systems are unavailable but later receive penalties, the cost of containment has been transferred to them.
For small businesses, billing and support disruption can have operational effects. A billing lockout may prevent account changes. A support delay may extend an outage. A missed dispatch may affect revenue. Telecom providers should treat customer-care continuity as part of resilience, not as administrative cleanup after the technical team is finished.
The evidence Frontier would need internally is concrete: support queue volumes during the incident, average response time, unresolved ticket backlog, billing exceptions, dispatch delays, enterprise escalations, customer complaints, and manual workarounds. These metrics show whether isolation preserved or degraded the customer promise.
Data-risk communication should be anti-fraud communication
When a telecom provider says personally identifiable information may have been accessed, the customer needs more than a list of fields. They need to understand how those fields can be misused. Telecom account data can support fake support calls, SIM or service-transfer scams, phishing about outages, refund scams, equipment-return scams, and account-recovery attempts. Even if Frontier's incident did not involve every one of those scenarios, the notice should prepare customers for realistic abuse patterns.
Anti-fraud communication should be specific. It should say that Frontier will not ask for passwords, full payment-card details, or two-factor codes through unsolicited calls. It should tell customers to use official channels and how to verify them. It should warn that scammers may refer to the cyber incident, account credits, service restoration, data monitoring, or equipment replacement. It should help customers distinguish a legitimate breach notice from a copycat.
This is especially important because telecom customers vary widely. Some are security professionals. Some are elderly. Some manage a family account. Some operate a business. Some speak English as a second language. Some have limited access to other communication channels. A notice written only for lawyers and regulators may technically disclose facts while failing to protect people.
Anti-fraud communication should also continue after the first mailing. If scammers exploit the incident later, the company should update support pages and customer alerts. If common questions emerge, FAQs should change. If customers report fake calls, the company should identify themes and warn others. The data-risk response is not static once letters are sent.
For Frontier, the settlement and complaint context indicates that customer-data questions remained alive after the initial filing. That makes fraud-aware communication more important. A legal settlement may provide benefits, but customers also need everyday guidance about suspicious contact. The two forms of remediation should reinforce each other, not live in separate silos.
Network operations and corporate IT need defensible separation
Telecom resilience depends on the separation between corporate IT and network operations. A cyber incident in corporate systems should not automatically endanger core service delivery. Conversely, an incident affecting network-management systems may require different urgency and disclosure. Frontier's public filing did not provide a full architecture map, but the accountability question is whether the company could defend the boundary between internal IT containment and service continuity.
Defensible separation includes technical controls: segmentation, privileged-access management, separate credentials, monitoring, change-control separation, backup isolation, and limited trust between office systems and operational systems. It also includes procedural separation: different escalation paths, different recovery priorities, and clear decision rights for systems that affect customer connectivity. A telecom provider should know which systems can be shut down without affecting service and which require continuity alternatives.
That boundary should be tested. Tabletop exercises should ask what happens if attackers access corporate identity systems, customer-care systems, billing systems, network-management tools, or vendor remote-access paths. Each scenario has different customer impact. If the exercise treats every system as the same, the response will be too blunt. If it treats corporate IT as unrelated to customer service, the response will miss the customer-care layer.
The evidence should include service-status analysis. During and after containment, did network operations remain within expected performance? Were outages correlated with cyber response actions? Were repair dispatches delayed? Were enterprise service-level commitments affected? Did customer support have enough information to distinguish a network outage from an account-system problem? These are operational questions, but they shape public trust.
The boundary also matters for cyber insurance, regulators, and investors. A company that can show corporate IT compromise did not compromise network operations has a stronger resilience story. A company that cannot explain the boundary leaves stakeholders guessing. In telecom, guessing is expensive because customers depend on communications for other forms of resilience.
Enterprise and public-sector customers need tiered notice
Residential customers need clear public guidance. Enterprise and public-sector customers often need more structured updates. They may have their own incident-response teams, business-continuity obligations, regulatory duties, and downstream users. A hospital, school district, local government, utility, or business customer may need to brief leadership or activate contingency plans if telecom support or services are impaired.
Tiered notice does not mean privileged customers receive truth while others receive vague language. It means different customers receive the level of operational detail they need. An enterprise customer may need account-team briefings, service-specific status, escalation contacts, and expected restoration timelines. A public-sector customer may need continuity coordination. Residential customers need safe-channel guidance and plain explanations. The facts should align across tiers.
The incident plan should define these tiers before a crisis. Which customers are critical? Which account teams contact them? Which updates require legal review? Which information can be shared under confidentiality? Which service metrics are available? Which regulators or public authorities must be informed? Waiting until a cyber incident to build the list creates delay and inconsistency.
Tiered notice also helps prevent rumor. If enterprise customers learn about the incident from an SEC filing or news article before account teams contact them, trust suffers. If public agencies cannot get clear answers, they may assume service risk is greater than it is. If residential customers see enterprise-only updates quoted online, they may feel excluded. A planned communication ladder reduces these tensions.
For Frontier, the public filing was an investor disclosure. It was not designed to answer every customer question. The accountable response should translate that disclosure into customer-specific guidance quickly. Filing with the SEC is necessary for material public-company events, but it is not a substitute for customer communication.
Recovery metrics should survive public scrutiny
A telecom cyber incident creates many possible recovery metrics. The company may measure restored systems, closed tickets, patched vulnerabilities, reset credentials, cleared alerts, completed notices, support volumes, customer complaints, legal claims, and financial impact. The public accountability challenge is to choose metrics that reflect customer risk rather than internal activity alone.
Useful metrics include time to detect unauthorized access, time to contain, time to restore critical customer functions, time to issue data notices, number of affected customers, support backlog, billing exceptions, service-impact reports, fraud reports, and post-restoration control changes. Each metric answers a stakeholder question. Customers ask whether they can rely on service and protect themselves. Regulators ask whether obligations were met. Investors ask whether impact is material and controlled. Employees ask whether procedures worked.
Metrics should be preserved in a lessons-learned record. NIST's recovery guidance emphasizes validation and improvement; a telecom provider should use the incident to update runbooks, contact lists, backups, segmentation, and communication templates. If the same metrics are not tracked in the next exercise, lessons may remain rhetorical.
Public scrutiny can be uncomfortable, but it can improve discipline. A company that knows it may later have to explain restoration timing, notice scope, and control changes is more likely to document decisions as they happen. That documentation protects the company from speculation and protects customers from vague closure.
The most important recovery metric may be the one hardest to publish: customer uncertainty reduced. Did customers know what worked, what did not, what data was at risk, and what to do? If the answer is no, the technical recovery may have outrun the trust recovery. For a telecom provider, trust recovery is not optional. It is part of connectivity.
The incident should reshape procurement and vendor oversight
Telecom providers depend on vendors for software, equipment, support tooling, cloud services, managed security, billing platforms, customer-relationship systems, and field operations. A cyber incident that disrupts internal systems should trigger vendor oversight questions. Which vendors had access? Which vendor systems were dependencies during recovery? Which contracts required incident cooperation? Which vendors could delay restoration? Which vendor logs were needed for scope analysis?
This matters because customers do not separate Frontier from its vendor chain. If a third-party system affects billing, repair, or support, customers still see Frontier as accountable. The company can outsource functions, but it cannot outsource the public promise of communications service. Vendor oversight should therefore be part of the post-incident repair record.
Procurement should require evidence-ready contracts. Vendors should agree to timely incident notification, log preservation, forensic cooperation, access-control standards, recovery support, and customer-impact coordination. If a vendor controls a critical system, the contract should define emergency access and continuity expectations. Otherwise, the company may discover during containment that it lacks the rights or data it needs.
The same logic applies to managed security tools. Monitoring vendors may detect signals, but Frontier must ensure those signals feed the right decision process. Backup vendors may support recovery, but Frontier must test restoration. Cloud providers may host systems, but Frontier must know dependencies. Accountability stays with the operator because the operator faces customers and regulators.
Adding vendor oversight to the Frontier analysis prevents a narrow internal-only review. A modern telecom provider is an ecosystem. A credible cyber repair examines the ecosystem.
Customers need a practical continuity checklist too
Although the operator owns the main control surface, customers also need practical continuity habits. Households should know how to verify official provider messages, keep account recovery information current, and avoid paying bills through links in unsolicited messages. Small businesses should know alternate support contacts, backup connectivity options, payment-terminal dependencies, and how to document disruption if service or support fails. Public-sector and enterprise customers should maintain escalation paths and continuity plans that do not depend on one provider portal being available.
Those customer actions do not reduce Frontier's accountability. They reflect the reality that communications service is a shared dependency. The operator must design reliable systems and notices; customers can still prepare for temporary uncertainty. The best provider communication helps customers take these steps without blaming them for the incident.
For Frontier and other telecom operators, publishing practical checklists after a cyber incident can reduce confusion. A checklist can tell customers how to check service status, verify billing messages, report suspicious contact, protect account credentials, and reach support safely. It can also tell customers what the company will not ask for. That is useful even if the technical incident is already contained, because scams and confusion often follow later.
The checklist should be accessible from stable official pages and not only from email. Customers who suspect phishing should be able to navigate independently to the guidance. This small design choice can turn communication into a security control. It also gives support agents a consistent reference, reduces contradictory explanations across channels, and helps customers understand that restoration, billing, account security, and fraud awareness are related but separate tasks.
In a communications incident, that clarity is itself a form of service continuity, especially for customers who have no backup provider and must decide quickly which messages to trust during service stress. Confident guidance lowers harm while the technical teams finish deeper repair.
Additional evidence boundary
For Frontier Communications made telecom system isolation a customer-continuity test, the additional evidence boundary is to keep confirmed facts, evidence-backed inference, and unknown information separate. That separation matters because an event involving frontier communications cyberattack telecom continuity can be described as a technical problem, a contract problem, or a communications problem depending on which actor is speaking.
The accountability analysis therefore has to return to practical control: who could change the configuration, limit exposure, accelerate detection, authorize notification, or prove that repair had reached the affected users.
This lens adds a careful test of root cause and triggering event. The trigger explains why the event became visible at a particular moment; the root cause requires evidence about design, control, governance, and verification choices that existed before that moment. Contributing conditions such as dependency, delegation, change windows, contracts, logs, and incentives should be evaluated without treating a company statement as the complete truth or turning a possibility into a settled conclusion.
The same discipline applies to detection failure, response failure, and recovery failure. The public record should show when the signal was seen, who had authority to act, what customers or regulators were told, and which additional evidence would make the conclusion stronger or weaker. While those elements remain partial, the responsible conclusion is not an extra accusation; it is a more precise map of responsibility, uncertainty, and the identity and access controls that a later audit should verify.