Data Ownership, Owners and Custodians
In the CSSLP Secure Software Requirements domain, data ownership addresses the question of who is accountable for the information a software system processes, stores, and transmits. Establishing ownership early in the lifecycle ensures that security requirements such as classification, access control, retention, and privacy are driven by business accountability rather than left to developers to guess. A data owner is typically a senior business stakeholder, not an IT or development person, who is ultimately responsible and accountable for a specific set of data. The owner determines the data's classification level (for example, public, internal, confidential, or restricted), defines who may access it and under what conditions, approves exceptions, decides on retention and disposal rules, and accepts residual risk. Because ownership carries accountability, it cannot be delegated away even if the day-to-day tasks are performed by others. In requirements engineering, the owner's decisions become the basis for confidentiality, integrity, and availability requirements, as well as regulatory and contractual obligations tied to the data. A data custodian, by contrast, is responsible for the technical and operational protection of the data according to the owner's direction. Custodians are usually IT operations, database administrators, cloud providers, or system administrators. Their duties include implementing access controls, encryption, backups, patching, logging, monitoring, and secure disposal. Custodians execute controls; they do not decide policy. Developers and the software itself often act in a custodial capacity when handling data at rest, in transit, or in use. Separating these roles supports separation of duties and clear accountability. During requirements gathering, the CSSLP professional should identify each data element, document its owner, map the custodial responsibilities, and translate the owner's protection needs into verifiable security requirements. This alignment reduces ambiguity, supports compliance with laws such as GDPR or HIPAA, and ensures that security controls reflect the true business value and sensitivity of the data.
Data Ownership, Owners and Custodians (CSSLP Domain 2: Secure Software Requirements)
Every secure software requirement ultimately traces back to a simple question: whose data is this, how sensitive is it, and who is accountable for protecting it? If nobody owns the data, nobody decides how it should be classified, how long it should be kept, who may access it, or what controls the software must implement. The result is software that either over-protects (expensive, slow, unusable) or under-protects (breaches, regulatory fines, loss of trust).
The CSSLP places this topic in Domain 2, Secure Software Requirements, because data ownership is a requirements-gathering activity. Before you can write security requirements for confidentiality, integrity, availability, privacy, retention or disposal, you must identify the data owner and get the owner to classify the data. The owner's classification decisions drive the functional and non-functional security requirements that developers later implement. Regulations such as GDPR, HIPAA, PCI DSS, GLBA and SOX also explicitly expect organizations to assign accountability for data, so ownership is a compliance requirement as well as a security best practice.
2. What It Is: Key Roles and Definitions
Data Owner (Information Owner)
The data owner is a business role, usually a senior manager or executive in the business unit that creates or uses the data. The owner is accountable for the data. Key responsibilities include:
- Determining the classification (sensitivity level) of the data, e.g., Public, Internal, Confidential, Restricted.
- Defining who may access the data and approving access requests (authorization decisions).
- Specifying protection requirements: encryption, retention periods, backup needs, acceptable use, disposal rules.
- Accepting residual risk related to the data.
- Periodically reviewing classification and access rights.
Important: the data owner is not normally the IT department and is not the person who merely types the data in. Ownership follows accountability, not keyboard access. The owner can delegate tasks but cannot delegate accountability.
Data Custodian (Information Custodian)
The custodian is typically a technical role (IT operations, database administrators, system administrators, cloud operations, sometimes the development team). The custodian is responsible for implementing and maintaining the controls the owner has specified. Responsibilities include:
- Implementing access controls, encryption, backups and logging as directed.
- Performing day-to-day protection, storage, backup/restore and recovery.
- Ensuring availability and integrity of systems holding the data.
- Reporting incidents and control failures to the owner.
The custodian does not decide the classification or who gets access; the custodian executes the owner's decisions. A good memory hook: the owner is accountable, the custodian is responsible.
Data Steward
A steward focuses on data quality and governance: accuracy, consistency, metadata, standards, and ensuring data is used in accordance with policy. Stewards often sit between the business owner and the technical custodian and may handle the day-to-day administration of ownership duties on the owner's behalf. On the exam, if a question emphasizes quality, consistency, definitions or compliance with data standards, think steward.
Data User
Any employee, contractor or system that accesses data to perform a job function. Users must follow acceptable use policies and handle data according to its classification. Users have responsibilities but not ownership.
Data Subject
The individual the personal data is about (a customer, patient, employee). Under privacy laws such as GDPR, the data subject has rights (access, rectification, erasure, portability). The subject is not the owner in the organizational sense, but the subject's rights create requirements the software must support.
Data Controller and Data Processor (privacy terminology)
Under GDPR, the controller determines the purposes and means of processing personal data (conceptually similar to the owner); the processor processes data on the controller's behalf (conceptually similar to a custodian, often a cloud provider or outsourcer). Expect the exam to test whether you can map these privacy terms to owner/custodian concepts.
System Owner / Application Owner
Accountable for the system or application rather than the data inside it. The system owner ensures the system is built, operated and maintained securely and works with data owners whose data the system processes. A single system can hold data belonging to many data owners.
Senior Management / Executive Management
Ultimately accountable for the entire information security program and for ensuring owners are appointed. If a question asks who holds ultimate responsibility for protecting organizational information, the answer is senior management.
Security Officer / CISO / Privacy Officer
Advisory and oversight roles. They develop classification policy, provide frameworks and tools, audit compliance, and advise owners, but they do not own the business data.
3. How It Works in Practice
Step 1: Inventory and discover data. Identify what data the software creates, stores, processes and transmits. Data flow diagrams produced during requirements and threat modeling are a primary input.
Step 2: Assign ownership. Each data set must have a named owner. Ownership is normally assigned to the business function that originates the data or has the greatest business stake in it. Policy should define how ownership is assigned and transferred (e.g., when an owner leaves the organization).
Step 3: Classify the data. The owner classifies the data using the organization's scheme. Classification considers confidentiality, integrity and availability impact, regulatory requirements (PII, PHI, cardholder data, financial data), and business value. Classification drives labeling (marking data electronically or physically) and handling requirements.
Step 4: Define protection requirements. Based on the classification, the owner (with security advice) specifies requirements. For the CSSLP, these become software security requirements: encryption at rest and in transit, access control model (RBAC, ABAC), audit logging, input validation, masking in non-production environments, retention and secure disposal, anonymization or pseudonymization for privacy, availability and recovery objectives.
Step 5: Custodians implement controls. Developers, DBAs and operations teams build and operate the controls. Custodians also implement backup, replication, key management and monitoring consistent with the owner's requirements.
Step 6: Users access and handle data per acceptable use and classification rules, with access approved by the owner.
Step 7: Monitor, review and reclassify. Ownership is lifecycle-based. Data sensitivity may change (e.g., a product launch date becomes public). Owners periodically review classifications and access rights; custodians provide reports and evidence; auditors verify.
Step 8: End of life. The owner authorizes retention periods and disposal; the custodian performs secure deletion or media sanitization and provides evidence.
4. Connection to the Software Development Lifecycle
- Requirements: Owners provide classification and privacy requirements; the team documents them as security requirements and acceptance criteria.
- Design: Architects design data stores, encryption, segregation and access control to satisfy owner requirements; threat modeling uses classification to rank assets.
- Implementation: Developers (acting as custodians of code and often of test data) must not use real production data in testing without owner approval; masking or synthetic data is preferred.
- Testing: Verify that controls for each classification level work as specified.
- Deployment and operations: Custodians operate the system; owners approve access and review logs.
- Disposal: Data and media are sanitized per owner-approved retention schedules.
5. Common Misconceptions the Exam Exploits
- IT is not the data owner just because the data lives on IT systems; IT is the custodian.
- The person who collected or entered the data is not automatically the owner.
- The security team does not classify business data; it provides the classification scheme and advises.
- The custodian does not approve access requests; the owner does.
- Accountability cannot be outsourced. Even if a cloud provider is the custodian or processor, the organization (owner/controller) remains accountable.
- Classification is based on sensitivity and impact, not on cost or difficulty of protection.
6. Exam Tips: Answering Questions on Data Ownership, Owners and Custodians
Tip 1: Decide between accountable and responsible. Read the question for the verb. Decides, classifies, approves, accepts risk, determines, authorizes point to the owner. Implements, maintains, backs up, configures, performs, operates, protects on a day-to-day basis point to the custodian.
Tip 2: Business versus technical. If the question describes a business manager, department head, product manager or executive in a business unit, think owner. If it describes a DBA, system administrator, operations team, or cloud provider, think custodian.
Tip 3: Watch for the trick answer of IT or the security officer. When asked who should classify data or approve access, IT and the CISO are common distractors. The correct answer is the data owner.
Tip 4: Ultimate responsibility goes to the top. If the question asks who is ultimately responsible for data protection in the organization, select senior or executive management, not the owner or custodian.
Tip 5: Map privacy terms. Controller behaves like owner (determines purpose and means); processor behaves like custodian (acts on instructions). The data subject is the individual the data is about and is the source of rights-based requirements, not the organizational owner.
Tip 6: Quality and governance signals mean steward. If the scenario talks about accuracy, consistency, data definitions, metadata or governance standards, the best answer is likely data steward.
Tip 7: Classification comes first. In a question asking what must happen before security requirements for data can be defined, the answer is assigning an owner and classifying the data. Classification drives controls, labeling and handling.
Tip 8: Delegation versus accountability. If an answer option says the owner transfers accountability to the custodian or to a third party, it is wrong. Tasks can be delegated; accountability cannot.
Tip 9: Test data scenarios. If developers want to use production data for testing, the correct approach is owner approval plus masking, anonymization or synthetic data. Using live data without owner approval is never the best answer.
Tip 10: Think like ISC2. Choose the answer that reflects policy, governance and clearly defined roles, that follows the organization's classification scheme, and that keeps the business accountable while technical teams implement. Avoid answers that rely on individual judgment of technical staff about how sensitive data is.
7. Quick Review Summary
- Owner: business role, accountable, classifies data, approves access, defines protection and retention requirements, accepts risk.
- Custodian: technical role, responsible, implements and maintains controls, backups, availability and integrity.
- Steward: data quality, governance and standards.
- User: follows acceptable use and handling rules.
- Subject: the individual the personal data describes; source of privacy rights.
- Controller/Processor: privacy-law equivalents of owner/custodian.
- Senior management: ultimately accountable for the security program.
- Core principle: Ownership and classification are the starting point for all secure software requirements concerning data; accountability stays with the business and can never be outsourced.