How to Create a Small Business Disaster Recovery Plan

A disaster recovery plan gives a small business a practical way to continue serving customers and restore essential operations after a cyberattack, technology failure, fire, flood, severe weather event, utility outage, supplier collapse, or other major disruption. The strongest plan is not a generic template stored and forgotten. It is a tested operating system for making decisions when people are under pressure, information is incomplete, and every hour of downtime matters.

Resilient operations depend on documented priorities, protected systems, and tested recovery procedures.

This guide uses a WikiHow-style sequence to help owners build a plan from the ground up. It covers business impact analysis, recovery objectives, backups, alternative work methods, vendor dependencies, employee safety, crisis communication, financial readiness, exercises, and continuous improvement. Adapt the recommendations to your industry, location, contracts, legal duties, and risk profile. Safety, emergency services, and qualified professional advice should always take priority when an event creates physical danger, legal exposure, or a serious cybersecurity incident.

What You Will Need

• A current list of employees, vendors, systems, facilities, and business processes
• Recent financial information and service obligations
• Access to backup, insurance, security, and vendor documentation
• Participation from the people who actually perform critical work
• A secure place to store the finished plan online and offline

Part 1: Understand What Must Be Recovered

Step 1: Define what disaster recovery means for your business

Start by describing disaster recovery in operational language rather than treating it as an IT-only project. Your plan should explain how the company will restore the people, systems, data, suppliers, facilities, communications, and financial processes required to serve customers after a serious disruption. Include cyberattacks, hardware failures, prolonged power loss, fire, flood, severe weather, telecommunications outages, vendor failures, and the sudden loss of a key employee. This broad definition prevents the common mistake of building a backup plan that protects files but leaves the business unable to invoice, communicate, fulfill orders, or make decisions. Write a one-paragraph purpose statement that identifies the plan owner, the situations that can activate it, and the result the plan is intended to achieve. Keep the language simple enough for a new employee to understand during a stressful event. A useful purpose statement might say that the company will protect life and safety first, stabilize the incident, restore essential services in priority order, communicate accurately, and return to normal operations without creating additional risk. Treat this statement as the anchor for every later decision.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 2: Assign a recovery leader and a small response team

A plan without named decision makers often fails because everyone waits for someone else to act. Appoint one recovery leader and at least one alternate. Then create a compact response team covering operations, technology, finance, customer communication, employee welfare, and vendor coordination. In a very small company, one person may cover several roles, but the responsibilities still need to be written down. Give each role authority limits, contact details, and a short checklist of immediate actions. Decide who may shut down systems, contact emergency services, approve emergency spending, speak publicly, notify customers, and declare that normal operations have resumed. Include alternates because the primary contact may be unavailable or personally affected by the incident. Store the team list in more than one place: a protected cloud document, an offline copy, and a printed copy away from the main workplace. Review the list whenever staffing changes. During a crisis, clarity of authority is more valuable than a large committee. The goal is not to create bureaucracy; it is to eliminate confusion during the first critical hour.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 3: List your essential products, services, and obligations

Create an inventory of what the business must continue or restore to survive. Begin with customer-facing products and services, then add supporting activities such as payment collection, payroll, regulatory reporting, purchasing, shipping, customer support, and data access. For every activity, record its owner, the people who know how to perform it, the systems and records it requires, the suppliers it depends on, and the consequences if it stops. Separate essential work from convenient work. A weekly marketing report may be useful, but processing customer payments or protecting regulated records may be essential. Consider contractual deadlines, service-level promises, and legal obligations that continue even during a disruption. This exercise exposes hidden dependencies. For example, an online store may appear to depend mainly on its website, but it also relies on payment processing, inventory records, shipping labels, warehouse access, email, and customer support. Rank activities by the damage caused by one hour, one day, three days, and one week of downtime. This ranking becomes the basis for recovery priorities and prevents the team from restoring low-value tools before revenue-critical functions.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 4: Conduct a practical business impact analysis

A business impact analysis estimates how interruption affects revenue, expenses, customers, employees, reputation, and compliance over time. For each critical activity, calculate direct lost sales, delayed cash collection, overtime, replacement costs, contractual penalties, refunds, and the cost of manual workarounds. Add nonfinancial effects such as customer frustration, employee safety concerns, damaged trust, and missed regulatory deadlines. Avoid false precision. A range is often more useful than an unsupported exact figure. Ask department owners what happens after four hours, twenty-four hours, three days, and two weeks without the activity. Identify the point at which delay becomes unacceptable. Note seasonal differences; a retailer may tolerate downtime differently during a quiet month than during a major sales period. Use the analysis to justify investments. If one day without the order system could cost far more than a tested backup solution, the priority becomes obvious. Revisit the analysis annually or after major changes. It should reflect the current business, not the company that existed when the plan was first written.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 5: Set recovery time and recovery point objectives

Define two targets for every important system or process. The recovery time objective is the maximum acceptable period before the service must be restored. The recovery point objective is the maximum amount of recent data the business can afford to lose. A four-hour recovery time objective means the service should be usable within four hours. A one-hour recovery point objective means backups or replication should limit data loss to roughly the previous hour. These targets guide technology choices and spending. Not every system needs instant recovery. Email, payroll, order processing, design files, and archived records may have very different requirements. Set ambitious but realistic objectives based on the business impact analysis. Confirm that vendors can meet them and that contracts describe what is actually provided. Remember that a backup frequency is not the same as a recovery guarantee. Data may be backed up every hour but still take days to restore if the process has never been tested. Record assumptions, dependencies, and the person who approved each objective.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 6: Map systems, data, equipment, and dependencies

Build a dependency map showing what each critical process needs to operate. Include computers, mobile devices, servers, cloud services, internet connections, phone systems, payment terminals, authentication tools, printers, specialist equipment, software licenses, passwords, encryption keys, and physical records. Then connect each item to its vendor, administrator, renewal date, support contact, and replacement method. Document integrations that may fail silently, such as the link between an ecommerce platform and inventory software. Include utilities and facilities: electricity, water, cooling, building access, and safe workspace. This map helps the response team understand why restoring one application may not restore the process. Keep configuration details secure and limit access to people who need them. Do not place sensitive passwords directly in a widely shared plan; point to an approved password vault and explain the emergency-access procedure. Update the map after software migrations, office moves, acquisitions, or major vendor changes.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 7: Identify realistic threats and single points of failure

Review threats that are plausible for your location, industry, technology, and operating model. Consider fire, water damage, extreme heat, storms, earthquakes, civil disruption, theft, ransomware, phishing, insider mistakes, failed software updates, cloud outages, internet cuts, and supplier insolvency. Then look for single points of failure: one person who knows a key process, one internet provider, one administrator account, one warehouse, one payment processor, or one copy of an important record. Score each risk by likelihood, operational impact, and how quickly it could be detected. Focus first on high-impact risks with weak controls. Do not spend all planning time on dramatic disasters while ignoring common failures such as accidental deletion or a broken laptop. The objective is not to predict every event. It is to design capabilities that work across many events: alternate communication, tested backups, cross-trained staff, emergency purchasing, and clear authority.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Backups are valuable only when they are isolated, monitored, and successfully restored in tests.

Step 8: Create a layered backup strategy

Protect business data with multiple independent copies stored in different locations and technologies. A practical approach is to keep production data, a separate local or rapidly accessible backup, and an off-site or cloud copy that is isolated from the main environment. At least one copy should be resistant to routine deletion or ransomware, using immutability, version history, offline storage, or tightly controlled credentials. Back up not only documents but also databases, website files, configuration settings, email, accounting records, customer information, and the information needed to rebuild systems. Encrypt sensitive backups and control who can restore them. Match backup frequency to the approved recovery point objective. Monitor failures automatically and assign a person to review reports. Retention periods should cover both recent mistakes and slower discoveries, such as corruption noticed weeks later. Never assume that a cloud application automatically includes a complete customer-controlled backup. Read the service terms and test export and restoration procedures.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 9: Test restoration instead of trusting backup reports

A successful backup notification proves that a job ran; it does not prove that the business can recover. Schedule restoration tests for representative files, databases, virtual machines, and complete workflows. Verify data integrity, permissions, application compatibility, and the time required. Test with people who would perform the recovery during a real incident, not only the vendor. Record each test date, scope, result, duration, problems, and corrective actions. Include a scenario in which the usual administrator account is unavailable or compromised. For high-priority services, perform periodic full recovery exercises in an isolated environment. Confirm that restored systems can communicate with dependent services and that users can complete a real business transaction. Delete test data safely afterward. Restoration testing often reveals missing encryption keys, undocumented settings, expired licenses, or backups that exclude critical folders. Fixing these issues before a disaster is one of the highest-value activities in the entire plan.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 10: Design alternate ways to work

Plan how essential work will continue when the normal office, systems, or suppliers are unavailable. Options may include remote work, a temporary location, manual forms, mobile hotspots, alternate shipping providers, spare equipment, or a simplified service offering. Define which processes can operate manually and for how long. Prepare printable forms for orders, receipts, contact logs, and approvals, then describe how those records will be entered into systems later without duplication. Check whether employees have suitable devices, secure connectivity, and authorization to work remotely. For physical operations, identify alternate storage, production, or fulfillment arrangements. A workaround must be safe, legal, and financially controlled; speed does not justify bypassing essential security or approval requirements. Test the workaround with realistic volume. A manual process that handles five transactions may collapse when asked to handle five hundred.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 11: Prepare an emergency communications plan

Create message templates and contact procedures before emotions and uncertainty are high. Identify audiences: employees, customers, suppliers, insurers, landlords, regulators, banks, emergency services, and the public. Decide who approves and sends each type of message. Maintain contact lists outside the primary email system so they remain available during an outage. Use more than one channel, such as phone, text, email, website notices, and a designated social account. Messages should state what happened in confirmed terms, what services are affected, what people should do, when the next update will arrive, and where authoritative information will be posted. Avoid speculation and promises the business cannot keep. Protect personal information and follow breach-notification requirements applicable to the company. During a long disruption, communicate on a predictable schedule even when there is little change. Silence encourages rumors and repeated support requests.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

A cross-functional planning session exposes dependencies that a technology-only review can miss.

Step 12: Document vendor and supply-chain recovery options

List critical suppliers and service providers, their support contacts, account identifiers, escalation routes, contractual commitments, and known dependencies. Ask how they protect availability, back up data, communicate outages, and support customer recovery. Identify alternatives for services that could halt the business, such as internet, payments, hosting, shipping, raw materials, or payroll. Prequalify backup vendors where practical so the company is not negotiating from zero during a crisis. Keep copies of key contracts, insurance certificates, and technical instructions in the recovery repository. Watch concentration risk: several tools may appear independent while all rely on the same cloud region, telecommunications carrier, or subcontractor. Decide what evidence is required before switching providers and who can approve the cost. Review vendor resilience at renewal rather than treating price as the only criterion.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 13: Protect access credentials and emergency administration

Recovery often requires privileged access at exactly the moment normal authentication is disrupted. Use a managed password vault, multifactor authentication, role-based access, and separate administrator accounts. Create an emergency-access procedure with strong controls, logging, and more than one authorized person. Store recovery codes and encryption keys securely in separate locations. Remove access promptly when employees or contractors leave. Document how to regain control of domains, cloud accounts, payment platforms, and social accounts if the primary administrator is unavailable. Test the procedure without exposing secrets in the plan itself. Avoid shared passwords sent through email or printed in an unlocked binder. The recovery plan should explain where credentials are stored, who may retrieve them, and how use will be reviewed afterward.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 14: Plan for employee safety and availability

Business recovery begins only after immediate life-safety needs are addressed. Document evacuation, shelter, emergency contact, accountability, and medical-response procedures appropriate to the workplace. Clarify that employees should not enter unsafe buildings or handle electrical, structural, chemical, or fire hazards without qualified professionals. Plan for staff shortages caused by illness, transportation problems, family responsibilities, or regional emergencies. Cross-train essential roles and create concise operating guides. Establish realistic expectations for remote work and emergency schedules. Provide a method for employees to report their status and receive verified instructions. Consider payroll continuity and access to employee records. A plan that assumes every employee will be available immediately is not credible. Build teams with alternates and design minimum-service modes that can operate with fewer people.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 15: Organize financial and insurance readiness

Maintain accessible records needed to pay employees, collect revenue, document losses, and make insurance or assistance claims. Include account contacts, policy numbers, coverage summaries, deductibles, claim procedures, asset inventories, recent photographs, purchase records, leases, tax records, and supplier agreements. Store protected copies away from the main site. Establish an emergency spending limit and identify who may approve purchases when normal workflows are unavailable. Consider how long the business can meet fixed expenses during reduced revenue and whether a dedicated liquidity reserve is appropriate. Review insurance with a qualified professional and understand exclusions, waiting periods, cyber coverage, business-interruption provisions, and documentation requirements. Do not assume every disaster or loss is covered. After an incident, track expenses and decisions from the beginning. A clean log supports claims, accounting, and later review.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 16: Write clear activation and escalation criteria

Explain who can activate the plan and what conditions justify activation. Examples include loss of a critical system beyond its tolerance, evacuation of the workplace, confirmed ransomware, a major supplier failure, or a regional utility outage. Create severity levels so the response can scale. A minor incident may require only the system owner; a major incident may activate the full team and executive authority. State where the team will meet physically or virtually, how members are notified, and what information must be gathered during the first assessment. Include criteria for contacting emergency services, insurers, legal counsel, cybersecurity specialists, or regulators. The plan should support judgment rather than replace it. Avoid thresholds so rigid that leaders delay action while waiting for perfect confirmation.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 17: Build a step-by-step recovery sequence

Turn priorities into an ordered checklist. Begin with safety and incident stabilization, then protect evidence and prevent further damage. Restore communications, identity and access services, network connectivity, core data, customer-facing systems, finance, and lower-priority tools according to dependencies and approved objectives. For each action, name the owner, alternate, required information, estimated duration, validation method, and rollback option. Add decision points for switching to alternate vendors or manual processing. Include a final business validation step: a technically running system is not recovered until authorized users can complete the required process accurately. Keep technical runbooks separate when they contain sensitive details, but link them clearly from the main plan. Numbered checklists reduce missed steps and make handoffs easier during long incidents.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Keep the plan accessible, current, and usable from outside the primary workplace.

Step 18: Create an incident log and decision record

Use a standard log to record times, observations, actions, approvals, communications, expenses, and unresolved issues. Assign a scribe during major incidents so leaders can focus on decisions. Record facts separately from assumptions. Note who authorized system shutdowns, customer notices, vendor changes, emergency spending, and return to service. Preserve relevant screenshots, alerts, and correspondence according to legal and security requirements. The log helps incoming team members understand the situation, supports insurance and regulatory work, and provides evidence for the after-action review. Store it in a location that remains available if the normal collaboration platform fails. Protect confidential content and limit access appropriately.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 19: Train employees on the parts they must perform

Employees do not need to memorize the entire plan, but they must understand their roles, notification channels, safety expectations, and reporting procedures. Provide short role-based training rather than one long presentation. Teach staff how to recognize official emergency messages, report incidents, use alternate tools, protect customer information, and avoid spreading unverified information. Train alternates for essential functions and give them opportunities to practice. Include new employees and contractors where relevant. Keep attendance and completion records. Refresh training after major process changes and use brief exercises to maintain familiarity. A plan that only the author understands is not an organizational capability.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 20: Run tabletop exercises and technical tests

At least periodically, gather the recovery team and walk through a realistic scenario. Present information in stages: the office is inaccessible, the primary system is down, a key vendor is unavailable, or backups take longer than expected. Ask participants what they would do, what authority they need, what information is missing, and how they would communicate. Tabletop exercises are inexpensive and reveal gaps in roles and assumptions. Combine them with technical tests, call-tree tests, remote-work trials, and restoration drills. Avoid designing exercises only to produce a pass. Introduce reasonable complications and record weaknesses without blaming participants. Convert every finding into an owner, deadline, and tracked improvement.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 21: Set a safe return-to-normal process

Recovery is not complete when systems first come online. Define criteria for verifying security, data integrity, backlog processing, customer commitments, financial reconciliation, and employee safety. Decide who authorizes the transition from emergency procedures to normal operations. Reconcile manually captured transactions carefully to avoid duplicate orders, payments, or records. Monitor restored systems for instability and suspicious activity. Communicate the change to employees and customers, including any remaining limitations. Preserve incident records and backups needed for investigation. Return temporary access and emergency spending permissions to normal controls. A deliberate transition prevents the recovery effort from creating a second incident.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 22: Review the incident and improve the plan

Hold an after-action review soon enough that details remain clear, while avoiding a blame-focused atmosphere. Compare actual recovery times and data loss with objectives. Identify what worked, what failed, which decisions were delayed, and what customers or employees experienced. Review vendor performance, communications, backup quality, costs, and security. Prioritize corrective actions by risk, assign owners and deadlines, and update the plan, training, contracts, and technical controls. Share lessons with the people who need them while protecting confidential information. Improvement is the final stage of recovery and the beginning of stronger resilience.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

Step 23: Maintain the plan as a living business document

Set a review schedule, usually at least annually and whenever major changes occur. Trigger updates after office moves, new systems, staffing changes, vendor replacements, acquisitions, new products, or significant incidents. Assign ownership for every section and record version history, approval date, and next review date. Confirm contact details and test document access. Remove obsolete instructions that could mislead responders. Keep a concise quick-action version for emergencies and a detailed version for planning and training. The best plan is not the longest document; it is the current, tested plan that people can find and follow under pressure.

Action checklist

• Write the decision or procedure in plain language.
• Name the responsible person and an alternate.
• Record the tools, contacts, approvals, and dependencies required.
• Define how the team will verify that the step worked.

A 30-Day Implementation Schedule

During the first week, appoint the team, inventory critical activities, and collect contact and system information. In the second week, complete the business impact analysis, approve recovery objectives, and review backup coverage. In the third week, document workarounds, communications, vendor alternatives, financial procedures, and the ordered recovery checklist. In the fourth week, conduct a tabletop exercise and at least one restoration test, correct the most serious gaps, distribute controlled copies, and schedule the next review. A small company does not need to solve every resilience problem in one month, but it should finish the month with clear ownership, protected data, an actionable first-hour checklist, and a prioritized improvement list.

Common Mistakes to Avoid

• Treating disaster recovery as only an IT problem: customer communication, payroll, suppliers, facilities, and decision authority matter just as much.
• Keeping the only copy at the office: the plan must remain available when the building or primary systems are inaccessible.
• Depending on one person: every essential role and credential needs a controlled alternate.
• Buying backup services without testing restoration: recovery capability must be demonstrated, not assumed.
• Using outdated contact lists: incorrect numbers waste critical time.
• Ignoring manual-work reconciliation: temporary records must be entered safely without duplication.
• Failing to update the plan after change: new systems and vendors can invalidate old assumptions.

Frequently Asked Questions

How long should a small business disaster recovery plan be?

It should be long enough to guide action but short enough to use under pressure. Many businesses benefit from a concise emergency checklist supported by detailed appendices, technical runbooks, contact lists, and templates.

How often should the plan be tested?

Test important components throughout the year and conduct a broader exercise at least annually. High-risk or rapidly changing operations may need more frequent tests.

Is cloud storage enough for disaster recovery?

Cloud storage can be an important component, but it does not replace recovery planning. Businesses still need independent backups, access controls, restoration testing, vendor contingency, communication, and operating workarounds.

What is the difference between business continuity and disaster recovery?

Business continuity focuses on keeping essential operations functioning during disruption. Disaster recovery focuses more specifically on restoring systems, data, facilities, and capabilities. Small businesses should coordinate both.

Who should own the plan?

A senior leader should be accountable, while process owners, technology staff, finance, communications, and employees contribute. Ownership must include authority to test and improve the plan.

Can a very small business use this process?

Yes. A sole owner can simplify the team structure, but still needs alternates, protected credentials, backups, vendor contacts, financial records, and a practical recovery sequence.

Final Recovery-Readiness Checklist

• Critical activities are ranked and assigned recovery objectives.
• Backups cover essential data and have been restored successfully.
• Emergency contacts and decision authority are current.
• Employees know how to receive instructions and report their status.
• Alternate vendors, work locations, and manual procedures are documented.
• Insurance, financial records, and emergency spending rules are accessible.
• The recovery sequence has owners, alternates, validation steps, and escalation points.
• The plan has been exercised, corrected, approved, and scheduled for review.

Final Thoughts

A strong disaster recovery plan does more than help a company survive a rare catastrophe. The same work improves everyday operations by clarifying priorities, reducing dependence on individuals, strengthening backups, improving vendor oversight, and making responsibilities visible. Begin with the processes whose failure would hurt customers or cash flow fastest. Protect the information needed to restore them, practice the difficult steps, and improve the plan after every test and real incident. Resilience is not a document purchased once; it is a business capability built through preparation, ownership, and repeated proof.