Argentina's Law 25.326: Data Protection for Your Website

If your website serves people in Argentina, you're almost certainly handling personal data without giving it much thought: the email someone leaves in your contact form, the name and national ID on a new customer record, the phone number that comes in through chat, the shipping address from your online store. That everyday act puts you under Law 25.326 on the Protection of Personal Data, the rule that governs how personal data is collected, stored, and used in Argentina.

The good news is that you don't need to be a lawyer or a security expert to cover the essentials. Much of what the law asks of you translates into concrete decisions: what data you request, how you protect it, and how you respond when someone wants to exercise their rights. In this guide you'll see what Law 25.326 is, what habeas data means, the role the AAIP plays, what happens with the database registry, and—above all—what you can review on your website today to reduce risk.

This is a practical guide, not legal advice. The amounts of penalties, the deadlines, and the details of the database registry change over time. Whenever something is uncertain, we'll tell you to check the current text or consult a professional.

What Law 25.326 Is

Law 25.326, enacted in the year 2000, is Argentina's general rule for personal data protection. Its goal is to guarantee people's right to control the information that exists about them in databases, both public and private.

That law is also what puts into practice the constitutional right of habeas data, recognized in Article 43 of the National Constitution. In plain terms: anyone can find out what data about them is on record, what it's used for, and—if needed—demand that it be corrected or deleted.

It helps to nail down three roles from the start, because the law assigns you obligations depending on which one you are:

• Data subject: the person the information refers to. Your user or customer.
• Database controller: whoever decides why and how the data is processed. If it's your business or your product, that's usually you.
• Data processor: whoever processes data on behalf of the controller. Your vendors: hosting, email service, payment gateway, analytics tools.

Understanding this matters because responsibility toward the data subject remains yours even when you delegate the processing to a vendor. Your relationship with each processor should be documented.

What Habeas Data Means in Practice

Habeas data sounds like legal Latin, but the idea is very concrete: it's the action that lets any person access the data held about them and ask for it to be corrected, updated, or deleted if it's false, out of date, or processed improperly.

For you, as a site owner, habeas data isn't some distant courtroom procedure. It's the reason your product should actually be able to:

• Tell a user what data you store about them.
• Correct or update that data when they ask.
• Delete their data when appropriate.

If your website collects data but has no real way to handle these requests, you're piling up a risk that sooner or later someone will come knocking about.

The Principles That Govern Data Processing

Law 25.326 sets out a series of principles that must be met in any data processing. You don't need to memorize them word for word; what matters is grasping the intent, because they guide how you design your site:

• Lawfulness: databases can't have purposes that run contrary to the law.
• Purpose: data is collected for a specific, legitimate purpose and can't be used for something incompatible with that purpose. Don't ask for the national ID number "just in case."
• Quality: data must be accurate, adequate, and not excessive for the purpose. If you don't need a piece of data, don't ask for it.
• Consent: as a general rule, processing personal data requires the data subject's free, express, and informed consent (with exceptions the law itself defines).
• Information: when you collect data, you must tell the data subject what you're requesting it for, who the controller is, and what rights they have.
• Security: you're required to adopt technical and organizational measures to protect the data.
• Confidentiality: everyone involved in the processing must keep it confidential.

Pay attention to the security principle: the law doesn't ask for good intentions, it asks for concrete measures. Later we'll see how that becomes something observable from outside your site.

The Role of the AAIP

The enforcement authority for Law 25.326 in Argentina is the Agency for Access to Public Information (AAIP), a body that oversees both access to public information and the protection of personal data.

What does the AAIP do, and why should you care?

• It monitors compliance with Law 25.326 and issues complementary rules and regulations.
• It handles complaints and claims from data subjects when a controller fails to resolve them.
• It can open investigations, carry out inspections, and impose penalties (warnings, fines, and other measures the regulations provide for).
• It administers the database registry, which we cover in the next section.

Penalties can be significant and are updated over time. We don't cite an exact amount here because the values are adjusted periodically; if you need the current figure, verify it directly with the AAIP or your legal advisor. The practical point is simple: the authority exists, it receives complaints, and it has the power to impose penalties.

The Database Registry

Law 25.326 provides for a registry of personal databases with the enforcement authority. The idea is to give visibility into who processes data in the country and for what purpose.

This is where you have to be careful. The way you register, the deadlines, and the operational details of the registry have changed over time and depend on the current regulations and the rules the AAIP issues. Don't assume by default that the process is the same as it was a few years ago.

If your business or site maintains personal databases in Argentina, verify the applicability and the current procedure for the registry directly with the AAIP before concluding that you are (or aren't) required to register your databases. It's an administrative step, separate from technical measures, and it's best resolved with up-to-date information.

The important thing for you as a founder, merchant, or website owner: the registry is an administrative obligation that's worth checking with the official source. It's not something your code resolves, but it is something your compliance checklist should account for.

The Data Subject's Consent

Under Law 25.326, as a general rule you need the data subject's free, express, and informed consent to process their data. "Informed" means the person understands what data you collect, what for, and who the controller is.

Some practical pointers for your website:

• Consent must be documented in a way that lets you keep proof of it. On the web this usually means an explicit checkbox (not pre-checked) next to a link to your privacy policy.
• Avoid "bundled consent," where accepting the terms implies accepting any use. Separate what's necessary from what's optional, like marketing.
• Sensitive data (racial or ethnic origin, political opinions, religious beliefs, health or sex-life information, among others the law defines) is subject to a stricter regime. In general no one is required to provide it, and processing it demands stricter conditions. If your product touches it, review the framework carefully.
• Always make clear that the data is voluntary when applicable, and keep a record of when and how consent was given.

The day a data subject or the AAIP asks, you'll want to be able to show that you collected consent correctly.

Data Subject Rights

Law 25.326 grants people a set of rights that your product should be able to handle. The main ones:

• Access: the data subject can ask to know what data you hold about them and for what purpose. The law sets deadlines for responding to these requests.
• Rectification: they can demand that you correct inaccurate or incomplete data.
• Updating: they can ask you to bring outdated information up to date.
• Erasure: they can request that you delete data when appropriate.
• Confidentiality and objection: depending on the case, they can object to certain processing.

These deadlines and conditions can be updated through regulation, so verify the current terms and design your operation to meet them. In product terms, this translates into real flows: being able to show a user their data, edit it, export it, and genuinely delete their account—not just "deactivate" it.

Your Privacy Policy

The law expects the controller to inform data subjects about how their data is processed. In practice, this takes shape in your Privacy Policy page, which should describe, among other things:

• Who the controller is (your business or company) and its contact details.
• What data you collect and for what purposes.
• Whether the data is shared with third parties or transferred to other countries.
• The data subject's rights (access, rectification, updating, erasure).
• The channel and procedure for exercising those rights and filing complaints.

A clear, honest policy doesn't just help you comply: it also builds trust. People notice when you explain things without fine print.

Security Measures: Where Compliance Gets Technical

Here's the part many legal guides overlook. The security principle in Law 25.326 doesn't stay on paper: it shows up in things anyone can observe from outside your site.

Think of it this way: if an attacker can intercept the form where your customer types their name, email, and address, you're not applying "reasonable technical measures," no matter what your policy says. Some examples of observable security that back up compliance:

• HTTPS across the whole site, not just on the login or checkout. Personal data travels through many forms.
• Security headers (like HSTS and a solid Content-Security-Policy) that reduce interception and injection attacks.
• Cookies flagged as Secure and HttpOnly where appropriate, to protect your users' sessions.
• No obvious leaks: exposed admin paths, error messages that reveal internal structure, backups or configuration files publicly accessible.

These signals are auditable. In fact, they're exactly the kind of findings a scanner can detect in minutes. It's not that passing a scan automatically makes you "compliant" with Law 25.326 (compliance is broader than that)—it's that a weak technical configuration directly contradicts the security principle and is the first thing worth closing off.

With Pursecure you paste your site's URL and get a score from 0 to 100 with findings ranked by severity. Each finding comes with a plain-language explanation and a ready-to-use prompt to fix it, whether you apply it yourself, your team does, or your AI does. It's a fast way to see today how far your public surface is from the security principle. You can run a free scan at pursecure.app.

What to Review on Your Site Today

An actionable list, half legal and half technical, for any site that serves people in Argentina (online store, landing page, blog, booking system, or SaaS):

The legal and administrative side

• You have a privacy policy published and linked from the footer and your forms.
• You collect explicit consent (a non-pre-checked checkbox) and keep proof of when it was given.
• You only request the data you genuinely need for a declared purpose (the purpose and quality principles).
• There's a clear channel for the data subject to exercise their rights (access, rectification, updating, erasure) and a process to respond within the current deadlines.
• You've identified your processors (hosting, email, payments, analytics) and the relationship is documented.
• You've verified whether you're required to register your databases in the AAIP registry, checking the current procedure.
• If you process sensitive data, you've reviewed the stricter regime the law requires.

The technical side (observable)

• The entire site is served over HTTPS and HTTP traffic is redirected.
• HSTS is active and security headers are configured (CSP, X-Content-Type-Options, among others).
• Session cookies carry the Secure and HttpOnly flags.
• No admin paths, backups, or environment files are publicly exposed.
• Forms that collect personal data don't leak information in error messages.
• You have a process to genuinely delete a user's data when they request it.

If you checked all the technical boxes "by eye," it's worth confirming with a measurement. Many of these fail silently: HTTPS is there, but the redirect is missing; the cookie exists, but without Secure.

Conclusion

Complying with Law 25.326 isn't a one-and-done task you can forget about. The rule asks you to handle your users' data with purpose, information, consent, and—very concretely—security. The AAIP keeps watch, the database registry may apply to you (verify with the source), and your users have habeas data rights that your site must be able to handle.

The legal side is something you work through carefully and, if needed, with a professional. The technical security side is something you can start closing off today, because it's measurable. Paste your site's URL into pursecure.app/scan, review the findings by severity, and use the prompts to fix what the security principle requires of you. It's the most concrete step you can take this week toward real compliance.