Deployment, Operations, Maintenance, and Retirement

Introduction

Software development does not end when a system passes testing. A product creates value only when it is released safely, operated reliably, supported effectively, improved responsibly, and eventually retired without unacceptable business, legal, or security consequences. Deployment and operations therefore form an essential part of the Software Development Life Cycle (SDLC), not an administrative activity performed after development.

This chapter examines the transition from development to live service and the activities that follow. It covers release planning, environment management, data migration, deployment strategies, training, support, incident response, maintenance, technical debt, legacy modernization, and system retirement. These activities require cooperation among developers, testers, operations personnel, security specialists, users, managers, and external suppliers.

A useful operational principle is that a software system is a service with a lifecycle. Its success must be measured not only by features delivered, but also by availability, performance, security, recoverability, usability, cost, compliance, and the ability to change safely.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose of release planning and environment management.
2. Compare common deployment strategies and select an appropriate approach.
3. Plan data migration, user training, operational support, and handover.
4. Distinguish corrective, adaptive, perfective, and preventive maintenance.
5. Explain incident, problem, and change management.
6. Identify and manage technical debt and legacy-system risks.
7. Describe responsible system retirement, including data retention and disposal.
8. Apply operational metrics and governance practices to a realistic software case.

1. From Build to Service

Deployment is the controlled process of making a software system available in a target environment. It includes packaging, configuration, infrastructure preparation, database changes, security controls, verification, and communication. Release is the management decision to make a particular version available to users; deployment is the technical execution of that decision. A release may be deployed gradually, to a limited group, or to several environments before general availability.

Operations is the continuing work required to keep the system useful and dependable. It includes monitoring, capacity management, backup and recovery, access administration, vulnerability management, incident response, service support, and routine maintenance.

A production service has several important quality attributes:

• Availability: whether users can access the service when required.
• Reliability: the probability that the service performs correctly over a stated period.
• Performance: responsiveness and resource efficiency under expected workloads.
• Recoverability: the ability to restore service and data after failure.
• Security: protection of confidentiality, integrity, and availability.
• Maintainability: the ease with which the system can be understood and changed.
• Observability: the ability to infer internal system conditions from logs, metrics, traces, and events.

Operational design should begin during requirements analysis. For example, “the system shall be available” is incomplete unless availability targets, maintenance windows, recovery expectations, and measurement methods are defined.

2. Release Planning

Release planning converts approved product changes into a coordinated delivery. A release plan normally specifies the scope, version identifier, dependencies, readiness criteria, deployment sequence, responsible people, communication plan, rollback method, and post-release verification.

2.1 Release contents and readiness

A release may contain application code, database scripts, infrastructure definitions, configuration, documentation, test evidence, migration tools, and operational runbooks. A release candidate should be uniquely identifiable and reproducible. Building the same source and dependency definitions should produce the same deployable artifact, subject to documented environmental differences.

Typical readiness questions include:

• Have required functional, security, performance, and accessibility tests passed?
• Are unresolved defects understood and formally accepted?
• Are database changes backward compatible with the deployment sequence?
• Are monitoring alerts and dashboards ready?
• Are support staff trained?
• Has a rollback or forward-repair procedure been tested?
• Are privacy, licensing, and regulatory obligations satisfied?
• Is the business owner prepared to approve the release?

A go/no-go decision should be evidence-based. Pressure to meet a date must not silently convert known high-impact risks into production incidents.

2.2 Release risk and change control

A release risk assessment considers the probability and impact of failure, the reversibility of the change, the number of users affected, dependency complexity, data sensitivity, and the quality of testing. High-risk changes may require a formal change advisory process, additional approval, a maintenance window, or a phased rollout.

Change control is not intended to prevent all change. Its purpose is to make change visible, assessed, authorized, traceable, and reviewable. Emergency changes may follow an accelerated process, but they should still be documented and reviewed afterward.

3. Environments and Configuration Management

An environment is a combination of infrastructure, operating system, runtime, services, databases, network rules, configuration, and data used to run a system. Common environments include:

Environment parity means that non-production environments resemble production sufficiently for test results to be meaningful. Perfect parity is often expensive, but important differences must be documented. A defect caused by different database versions, network policies, or configuration values is commonly described as “works in development.”

Configuration should be managed as carefully as source code. Configuration includes connection endpoints, feature flags, resource limits, authentication settings, and integration credentials. Secrets must not be placed in source repositories or ordinary logs. They should be stored in an approved secrets-management facility, rotated, and accessed according to least privilege.

Infrastructure as Code (IaC) represents infrastructure through version-controlled definitions. It improves repeatability and auditability, but it does not eliminate the need for review, security testing, state management, and recovery planning. Configuration drift occurs when an environment changes manually or independently of its approved definitions. Drift should be detected and corrected rather than accepted as undocumented reality.

4. Data Migration

Data migration transfers, transforms, cleans, or restructures data between systems or schemas. It is often more dangerous than application deployment because errors may be difficult to reverse and may affect legal records, financial balances, or personal information.

A migration plan should identify:

1. Source and target data models.
2. Field mappings and transformation rules.
3. Required cleansing and validation.
4. Duplicate, missing, invalid, and orphaned records.
5. Data ownership and approval responsibilities.
6. Security, retention, and privacy requirements.
7. Migration duration and downtime assumptions.
8. Backup and rollback arrangements.
9. Reconciliation checks after migration.

A common pattern is extract, transform, load (ETL). Data is extracted from the source, transformed into the target representation, and loaded into the destination. A migration may instead use extract, load, and transform when the target platform provides the appropriate transformation capability.

Migration validation should occur at several levels. Record counts can reveal omissions, but counts alone are insufficient. Important totals, relationships, constraints, status values, dates, permissions, and representative business transactions should also be checked. For example, a financial migration should reconcile account totals and transaction totals, not merely the number of rows.

Two broad cutover patterns are common. In a big-bang migration, the old system is stopped, all data is migrated, and the new system is opened. This is simple conceptually but creates a concentrated risk and potentially long outage. In a phased migration, users, branches, data domains, or functions move in stages. This reduces the size of each transition but requires coexistence, synchronization, and more complex support.

5. Deployment Strategies

The appropriate strategy depends on risk, architecture, user tolerance, infrastructure cost, data design, and the ability to reverse a change.

5.1 Recreate or in-place deployment

An in-place deployment updates the existing service environment. It can be efficient and inexpensive, but a failed update may affect all users. It is most suitable for low-risk changes with strong backups and a reliable recovery procedure.

5.2 Blue-green deployment

Two production-like environments are maintained. The blue environment serves users while the green environment receives and verifies the new release. Traffic is then switched to green. If the new version fails, traffic can be returned to blue, provided data changes remain compatible.

Blue-green deployment can make application rollback rapid, but it may require duplicate infrastructure. Database changes are a special concern: a schema change that the old version cannot understand may prevent safe traffic reversal.

5.3 Rolling deployment

A rolling deployment updates instances gradually. During the process, old and new versions operate together. It reduces the need for duplicate infrastructure and limits the immediate blast radius, but requires compatibility between versions and careful monitoring.

5.4 Canary deployment

A canary release sends a small proportion of traffic to the new version. Technical and business indicators are compared with the existing version before exposure expands. Canary deployment is useful when the system can route traffic selectively and when meaningful monitoring is available. A small sample is not automatically representative; user groups, regions, device types, and workloads should be considered.

5.5 Feature flags

Feature flags separate code deployment from feature activation. A feature can be deployed but disabled, enabled for internal users, or enabled gradually. Flags reduce release coordination risk, but they create operational complexity. Old flags should be removed, ownership should be assigned, and flag combinations should be tested.

5.6 Rollback and forward repair

Rollback restores an earlier software version. It is appropriate when the prior version remains compatible with current data and external interfaces. Forward repair deploys a corrective version when reversing would risk data loss or incompatibility. Every release plan should state which approach is possible; “we can roll back” is not credible if the database migration is irreversible.

6. User Training, Handover, and Support

Technical success does not guarantee adoption. Training should be role-based and aligned with actual work. End users may need demonstrations, guided practice, quick-reference material, accessibility support, and explanations of changed procedures. Administrators and support personnel require deeper instruction in configuration, diagnostics, security, and recovery.

Operational handover should transfer knowledge, not merely documents. A useful handover package includes:

• System architecture and dependency diagrams.
• Installation and deployment procedures.
• Configuration and access information, excluding exposed secrets.
• Monitoring dashboards and alert interpretation.
• Backup, restore, and disaster-recovery procedures.
• Known errors, limitations, and workarounds.
• Support contacts and escalation paths.
• Service-level targets and maintenance schedules.
• Data-retention and privacy obligations.

Support commonly uses tiers. First-line support records and classifies user issues. Second-line support investigates application and configuration problems. Third-line support involves developers, architects, vendors, or specialist engineers. A clear escalation model prevents unresolved issues from circulating between teams.

A service-level agreement (SLA) defines measurable expectations between a provider and customer. It may specify availability, response time, restoration time, support hours, and reporting. An SLA should distinguish response from resolution: acknowledging an incident is not the same as restoring service.

7. Operations and Observability

Operations uses a feedback loop: observe the service, interpret evidence, act safely, and learn from outcomes. Monitoring should cover user-visible behavior as well as infrastructure. Useful signals include request success rate, latency, throughput, resource consumption, queue length, authentication failures, error rates, and business transactions.

Logs record events; metrics summarize measurements; traces show the path of a request across components. These sources should be correlated using timestamps and request or transaction identifiers. Logging must avoid unnecessary personal or confidential data, and access to logs must be controlled because logs can contain sensitive information.

Alerts should be actionable. An alert that fires frequently without requiring action creates alert fatigue and may cause a genuine failure to be ignored. Alert definitions should identify severity, affected service, evidence, immediate actions, and escalation requirements.

Two recovery measures are especially important:

• Recovery Time Objective (RTO): the maximum acceptable time to restore service after disruption.
• Recovery Point Objective (RPO): the maximum acceptable period of data loss measured in time.

For example, an RPO of 15 minutes means that, under the recovery design, the organization accepts losing at most approximately 15 minutes of recent data. It does not mean that recovery will necessarily finish within 15 minutes. An RTO of two hours concerns restoration time, not data-loss tolerance. Both targets must be supported by tested technical procedures and realistic resource assumptions.

Backups are not sufficient unless restoration is tested. A backup that cannot be decrypted, is incomplete, or depends on unavailable infrastructure is not a dependable recovery capability.

8. Incident, Problem, and Change Management

An incident is an unplanned interruption or reduction in service quality. Incident management aims to restore normal service quickly and reduce impact. It emphasizes detection, triage, communication, containment, workaround, recovery, and closure.

A problem is the underlying cause or potential cause of one or more incidents. Problem management seeks durable understanding and prevention. A post-incident review should examine contributing conditions, not merely identify an individual to blame. Useful questions include: What was expected? What happened? How was it detected? Which safeguards failed? What made diagnosis difficult? Which actions reduce recurrence?

A change is an addition, modification, or removal that may affect a service. Change management assesses risk, testing, approval, scheduling, implementation, and verification. These practices are related but distinct: an incident may require an emergency change; a problem investigation may create a planned change.

Severity and priority should be defined consistently. Severity describes impact, such as the number of users affected or whether a critical business function is unavailable. Priority combines impact with urgency, business commitments, safety, compliance, and available alternatives.

9. Software Maintenance

Maintenance begins after delivery and may consume more effort than initial construction. Four traditional categories are useful:

Maintenance must be controlled like new development. A small change can affect security, data integrity, performance, interfaces, and compliance. Regression testing is essential because existing behavior may depend on apparently unrelated code.

Corrective work is often urgent, but repeated emergency fixes may conceal a deeper problem. Preventive maintenance, dependency updates, automated testing, documentation, and architectural simplification reduce future risk. Maintenance prioritization should consider user value, risk reduction, regulatory deadlines, operational cost, and technical feasibility.

10. Technical Debt and Legacy Modernization

Technical debt is the future cost created when a design or implementation shortcut is accepted today. Like financial debt, it may be deliberate or accidental and may be manageable when visible. It becomes dangerous when interest accumulates through slower delivery, fragile releases, defects, security exposure, and dependence on scarce expertise.

Examples include obsolete dependencies, duplicated logic, poor automated test coverage, undocumented interfaces, manual deployment, tightly coupled modules, and unsupported infrastructure. Not every old component is technical debt; stable, well-understood code may be appropriate. Debt is identified by its consequences and remediation cost, not by age alone.

A debt register can record the item, cause, impact, evidence, owner, risk, estimated remediation effort, and review date. Teams should reserve capacity for debt reduction rather than treating it as work that will occur only when no feature remains.

Legacy modernization options include:

• Retain: continue operating with controlled risk.
• Rehost: move the system with minimal code change.
• Replatform: adopt a better runtime or managed service.
• Refactor: improve internal structure while preserving behavior.
• Rearchitect: change major technical structures.
• Rebuild: create a replacement with similar capabilities.
• Replace: adopt a commercial or alternative product.
• Retire: remove the capability when it is no longer needed.

A “big rewrite” is not automatically the best solution. A strangler approach gradually places new capabilities around an existing system and transfers functionality in stages. This can reduce transition risk, but it requires reliable interfaces, data synchronization, and a definite plan to remove the old path. Modernization decisions should evaluate business value, security, interoperability, skills, migration complexity, total cost, and reversibility.

11. System Retirement

Retirement is the controlled removal of a system, not simply switching off its servers. It begins with a decision that the system is obsolete, duplicated, uneconomic, unsafe, or replaced. Retirement planning should identify affected stakeholders, successor capabilities, dependencies, contracts, data obligations, and communication needs.

A responsible retirement process generally includes:

1. Inventory the system, interfaces, users, data, infrastructure, and suppliers.
2. Confirm the replacement service and acceptance criteria.
3. Freeze or control new functionality in the retiring system.
4. Migrate required data and validate it with owners.
5. Export records in a usable, documented format.
6. Define retention periods, legal holds, and disposal approvals.
7. Notify users, customers, regulators, and suppliers where necessary.
8. Disable integrations and access in a controlled sequence.
9. Revoke credentials, certificates, tokens, and administrative accounts.
10. Securely erase or destroy data and media when retention ends.
11. Update architecture records, asset inventories, contracts, and support procedures.
12. Monitor for residual traffic or attempted access after shutdown.

Data retention is not the same as keeping everything forever. Privacy and records-management principles generally require data to be retained for a justified period and then securely disposed of. Legal, contractual, tax, health, employment, or sector-specific requirements may apply. A retirement project should involve legal, security, privacy, and records-management specialists where appropriate.

12. Governance, Ethics, and Contemporary Practice

Deployment and operations create significant governance responsibilities. Access should follow least privilege, duties should be separated where practical, and production actions should be traceable. Personal data should be minimized, protected in transit and at rest, and processed for legitimate purposes. Changes affecting automated decisions should be explainable enough for responsible review, and users should not be harmed by silent system changes.

Regulated organizations may require evidence of approvals, test results, segregation of duties, vulnerability remediation, backup tests, and incident notification. Accessibility should be preserved after deployment; a technically successful release that excludes users with disabilities is not a quality release.

DevOps and platform engineering emphasize shared responsibility, automation, continuous feedback, and small, reversible changes. Continuous integration and continuous delivery can shorten release cycles, but automation magnifies both good and bad decisions. A pipeline requires protected branches, dependency controls, automated tests, security checks, approval gates suited to risk, artifact traceability, and rapid recovery.

Artificial intelligence can assist with log analysis, anomaly detection, test generation, incident summarization, and migration mapping. However, AI-generated recommendations may be incomplete, insecure, biased, or based on misleading operational data. Human review, data protection, auditability, and clear accountability remain necessary. AI should support—not replace—responsible engineering decisions.

13. Worked Application: Illustrative Case of a College Registration System

Background

A college operates a registration system used by students, lecturers, finance staff, and administrators. The existing application is difficult to maintain, has an unsupported database version, and becomes slow during registration week. A replacement web service has been developed.

Problem analysis

The system contains student profiles, course registrations, fee information, and historical results. A simple application deployment is insufficient because the database schema changes, personal data is involved, and a registration outage could prevent students from enrolling before deadlines. The college also lacks a mature support team.

Approach

The project team first creates a data inventory and assigns data owners. It maps old fields to the new model, removes duplicates, and tests migration using a masked copy. Reconciliation checks compare student counts, registration counts, fee totals, and sample student histories. The team documents exceptions rather than silently discarding records.

The new service is deployed to a staging environment that uses production-like database versions and network rules. Support staff receive role-based training, while students receive demonstrations and concise online guidance. A pilot is conducted with one department before broader rollout.

A blue-green deployment is selected for the application layer. The database uses an expand-and-contract approach: new fields are added while the old application still works; data is populated; the new application is enabled; obsolete fields are removed only after the old version is no longer required. This preserves compatibility during transition.

During the pilot, monitoring shows that response time is acceptable but an external finance integration occasionally times out. The release is paused, the integration is investigated, and a retry and queueing improvement is deployed before expansion. The college establishes an incident channel, escalation contacts, backup verification, and a daily release review during registration week.

Outcome

The replacement is introduced in stages rather than during a single high-risk cutover. The pilot exposes an integration problem while the affected user group is small. Data owners approve reconciliation results, and the old system is retained in read-only mode for a documented period. After retention and audit requirements are satisfied, access is revoked and the legacy infrastructure is securely decommissioned.

Learning points

The case demonstrates that deployment is a socio-technical activity. Technical compatibility, migration validation, user preparation, operational monitoring, support readiness, and retirement planning must be designed together. Phased release reduces exposure, but only when the organization can observe results and manage coexistence.

14. Challenges and Limitations

No deployment strategy removes all risk. Blue-green deployment may be unaffordable for large data platforms; canary deployment may miss rare failure conditions; rolling deployment can expose users to version inconsistency; and feature flags can create complex combinations. Rollback may be impossible after irreversible data changes.

Metrics can also mislead. High availability does not prove correctness, and low error rates may reflect missing monitoring. User satisfaction can fall even while infrastructure indicators appear healthy. Operational decisions should combine technical telemetry with business outcomes and user feedback.

Documentation decays, staff change roles, suppliers fail, and test environments differ from production. Consequently, operations must be treated as an ongoing capability. Exercises, audits, game days, recovery tests, access reviews, and post-incident learning provide evidence that plans work in practice.

Best-Practice Checklist

Before release:

• Define scope, dependencies, risks, approvals, and rollback or forward-repair options.
• Test the artifact, configuration, migration, security controls, and recovery procedure.
• Confirm monitoring, support coverage, training, and communication.
• Verify privacy, accessibility, licensing, and regulatory requirements.

During deployment:

• Use an authorized, traceable process.
• Make changes in controlled stages where practical.
• Monitor technical and business indicators.
• Communicate status and act on predefined stop criteria.

After deployment:

• Verify real user journeys and data integrity.
• Review incidents, alerts, performance, and support demand.
• Remove temporary access and obsolete feature flags.
• Record lessons and update runbooks.

During retirement:

• Validate replacement capability and migrated records.
• Apply retention, legal-hold, privacy, and secure-disposal requirements.
• Revoke access and monitor for residual dependencies.
• Preserve necessary documentation and audit evidence.

Chapter Summary

Deployment makes an approved software release available in a controlled environment, while operations keeps the resulting service secure, reliable, observable, and useful. Effective release planning defines scope, readiness, dependencies, communication, and recovery. Environment parity, configuration management, secrets protection, and infrastructure automation improve repeatability.

Data migration requires field mapping, cleansing, validation, reconciliation, ownership, and a realistic rollback or forward-repair strategy. Blue-green, rolling, canary, phased, and feature-flag approaches manage deployment risk in different ways. User training, operational handover, tiered support, monitoring, backups, RTO, and RPO connect technical delivery to service responsibility.

Incidents require rapid restoration; problems require investigation of underlying causes; changes require controlled assessment and traceability. Corrective, adaptive, perfective, and preventive maintenance sustain value after delivery. Technical debt must be made visible and reduced deliberately, while legacy modernization should be selected according to risk, value, cost, and reversibility. Finally, system retirement requires migration, retention decisions, secure disposal, access revocation, communication, and evidence that the old service has truly been removed.

Key Terms

Deployment: The controlled act of installing and enabling software in a target environment.

Release: An approved version or set of changes made available to users.

Environment: The infrastructure, software, configuration, and data context in which a system runs.

Configuration drift: Unplanned difference between an environment and its approved configuration definition.

Data migration: Moving, transforming, cleansing, or restructuring data between systems.

Big-bang migration: A migration performed in one major cutover.

Blue-green deployment: Switching traffic between two production-like environments.

Rolling deployment: Updating service instances gradually rather than all at once.

Canary release: Exposing a new version to a limited user or traffic group before expansion.

Feature flag: A control that separates code deployment from feature activation.

Observability: The ability to understand system condition through outputs such as logs, metrics, and traces.

Incident: An unplanned interruption or reduction in service quality.

Problem: An underlying or potential cause of one or more incidents.

Corrective maintenance: Maintenance that fixes discovered faults.

Adaptive maintenance: Maintenance that responds to changed environments or requirements.

Technical debt: Future cost or risk created by present shortcuts or poor design choices.

Legacy system: An existing system whose technology, design, or support constraints make change difficult.

Recovery Time Objective (RTO): The maximum acceptable time to restore service after disruption.

Recovery Point Objective (RPO): The maximum acceptable time-based amount of data loss after disruption.

System retirement: The controlled withdrawal, data disposition, and decommissioning of a software system.

Review Questions

Short Answer Questions

1. What is the difference between a release and a deployment?
2. Why should configuration be managed under version control?
3. Distinguish RTO from RPO.
4. What is the purpose of a canary release?
5. Name the four traditional categories of software maintenance.

Long Answer Questions

1. Explain the activities that should be included in a release plan and justify their importance.
2. Compare blue-green, rolling, and canary deployment strategies, including their risks and suitable contexts.
3. Describe a reliable data-migration process from planning through post-migration reconciliation.
4. Explain how incident management, problem management, and change management interact.
5. Discuss the technical, organizational, privacy, and governance issues involved in system retirement.

Analytical / Application Questions

1. A payment service must remain available while a new version is introduced, but its database schema is changing. Recommend a deployment strategy and explain how you would preserve compatibility and recovery options.
2. A support team receives hundreds of alerts every day, most of which require no action. Analyze the likely operational consequences and propose a redesign of monitoring and alerting.
3. An organization wants to replace a twenty-year-old student-information system with a complete rewrite in one year. Evaluate this proposal and recommend a modernization and migration approach using risk, data, user, and retirement considerations.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily concerned with making an approved software version available in a target environment?

A. Deployment

B. Requirements elicitation

C. Problem management

D. System retirement

Correct Answer: A. Deployment

Question 2

What is the main advantage of a canary release?

A. It eliminates the need for monitoring

B. It exposes the new version to a limited group before wider release

C. It guarantees that database rollback is possible

D. It requires no coexistence between versions

Correct Answer: B. It exposes the new version to a limited group before wider release

Question 3

Which practice best protects deployment credentials and API keys?

A. Embedding them in source code

B. Printing them in deployment logs

C. Storing them in an approved secrets-management facility

D. Sharing them through ordinary email

Correct Answer: C. Storing them in an approved secrets-management facility

Question 4

An RPO of 15 minutes specifies:

A. The maximum acceptable service-restoration time

B. The maximum acceptable period of data loss

C. The maximum number of users in a pilot

D. The maximum duration of a maintenance window

Correct Answer: B. The maximum acceptable period of data loss

Question 5

Which maintenance category adapts software to a new operating system or legal requirement?

A. Corrective

B. Adaptive

C. Perfective

D. Preventive

Correct Answer: B. Adaptive

Question 6

What is the primary purpose of problem management?

A. To restore service as quickly as possible during every incident

B. To approve all feature requests

C. To identify and address underlying causes of incidents

D. To archive retired software

Correct Answer: C. To identify and address underlying causes of incidents

Question 7

Why can database changes make rollback unsafe?

A. The old application may not understand the new schema or data

B. Database changes always delete every backup

C. Rollback never affects application behavior

D. Databases cannot be monitored during deployment

Correct Answer: A. The old application may not understand the new schema or data

Question 8

Which validation is most appropriate for a migration of financial records?

A. Checking only the number of database tables

B. Checking only whether the application starts

C. Reconciling important totals and representative transactions

D. Deleting records that fail an informal visual check

Correct Answer: C. Reconciling important totals and representative transactions

Question 9

Which statement best describes technical debt?

A. Any software that is more than five years old

B. Future cost or risk created by present shortcuts or poor design choices

C. A mandatory fee charged by cloud providers

D. A defect that can never be corrected

Correct Answer: B. Future cost or risk created by present shortcuts or poor design choices

Question 10

Which activity belongs in responsible system retirement?

A. Leaving old credentials active for convenience

B. Deleting all data immediately without retention review

C. Revoking access and applying approved retention and disposal rules

D. Avoiding communication with affected users

Correct Answer: C. Revoking access and applying approved retention and disposal rules