Data protection is a product decision

A privacy policy cannot compensate for a product that collects information without a clear reason, gives too many people access, or keeps records with no defined end point. The policy describes commitments; the software determines how much of the organization’s daily behavior can honor them.

That does not mean software is a legal person with independent duties. In most data-protection regimes, obligations attach to organizations and people according to what they decide and do. But the product’s data model, permissions, integrations and retention behavior can either make responsible handling possible or quietly undermine it.

Start with the purpose, not the data field

Before adding a field, event or analytics feed, define the decision or service it supports. “We may need this later” is not a useful product requirement. It encourages broad collection and makes it harder to explain to a person why the information is held, who can use it and when it should be removed.

Under Colombia’s Law 1581 of 2012, personal-data processing is guided by principles including purpose, freedom, accuracy, transparency, restricted access, security and confidentiality. The law also distinguishes the controller, which decides the purpose and means of processing, from a processor that handles data on the controller’s behalf. Consent and other legal conditions depend on the applicable rule and circumstances; a design team should not treat a checkbox as a universal legal basis. Colombia’s Law 1581 of 2012.

The General Data Protection Regulation in the EU similarly requires purpose limitation and data minimization, and calls for safeguards to be built into processing by design and by default. It is a useful comparison, not a substitute for checking which law applies to a particular organization, service and person. EU General Data Protection Regulation, Regulation (EU) 2016/679.

Make obligations possible in the product

Legal and privacy review can identify what an organization must do. Product and engineering teams have to turn those duties into working paths. A person’s request to access or correct information should reach the right team with enough context to find the relevant records. A deletion request should account for connected systems and retention obligations. A support agent should see only the information needed to resolve the case.

That calls for a map of what data exists, where it moves, which services receive it, who owns each purpose, and how long records remain. Permissions should follow roles and purpose. Retention rules need to reach backups, exports and downstream copies as far as law and technical design allow. Logs should make significant access and changes reviewable without collecting still more personal information than necessary.

Security controls also need an operational owner. Encryption, access review, backups, vulnerability handling and incident response are not one-time implementation tasks. They need assigned responsibility, evidence and a route for action when something fails.

Responsibility follows the real relationship

A contract may call a vendor a processor, but the label alone does not settle every legal question. The actual purposes, decisions and instructions matter. In Colombia, Decree 1377 of 2013 sets out requirements for arrangements between controllers and processors, including the scope of processing and the processor’s duties. It also requires controllers to be able to demonstrate measures that are appropriate and effective in proportion to the organization, data, processing and potential risks. Colombia’s Decree 1377 of 2013.

That is why software procurement and development should identify subprocessors, hosting locations, data flows, access by support staff, incident notification paths, deletion or return at exit, and what evidence each party can provide. The exact contractual and transfer requirements depend on the applicable law and arrangement. A vendor can help implement safeguards without replacing the customer’s own decisions and accountability.

In 2025, Colombia’s Superintendence of Industry and Commerce issued instructions concerning personal-data protection in technology-transfer processes, emphasizing preliminary compliance checks, risk management, documented decisions and protection by design for the entities within scope. This is a concrete reminder that a technology change can alter data flows and legal exposure; it is not a blanket rule for every software project. SIC guidance on data protection in technology transfers.

Do not design for perfect conditions only

Responsible data use includes the ordinary edge cases: a staff member changes roles; an integration sends duplicate records; a person withdraws authorization where that applies; a supplier relationship ends; an account is compromised; or an incident must be assessed quickly. If a product has no clear way to limit access, find affected records, suspend a flow or support an investigation, a written procedure may be difficult to carry out.

Not every processing activity requires the same assessment, control or notification. For example, the EU GDPR requires a data-protection impact assessment before processing likely to result in high risk to people’s rights and freedoms; it does not make the same assessment mandatory for every feature. Similar thresholds and procedures vary across laws. Legal counsel and the organization’s privacy lead should determine what applies to the specific processing.

Turn data protection into a release and operating discipline

For a new workflow, teams can make a small set of questions part of product discovery and release review: What is the purpose? Which personal data is truly needed? Who may see or change it? How do people exercise applicable rights? What is the retention rule? Which providers receive the data? What happens during an incident or when the service ends? What evidence shows that the controls work?

These questions require product, engineering, security, operations, procurement and legal expertise. They are easier to answer while the workflow and architecture are still being shaped than after unnecessary data has spread across systems and contracts.

The legal analysis must be specific to the organization, the people affected, the type of data and the countries involved. The product responsibility is more immediate: make the intended use explicit, constrain access and retention, support people’s rights, and keep enough operational evidence to review what happened. That is how privacy language becomes a system people can be accountable for.

This article is general information, not legal advice. Organizations should obtain advice on the laws applicable to their own processing.