Technology Responsibility: A Compliance and Security Study

Executive summary

A regulator calls on a Tuesday. The questions are plain. Who owns the risk in the system that failed. What control was supposed to treat it. Where is the evidence that the control actually worked, and when did the board last look at any of it. An organization either has those answers within reach or it does not. The distance between the two is the subject of this study.

Good intentions stopped counting for much some time ago. Technology responsibility is now a set of enforceable duties, legal, contractual, and ethical, that an organization has to demonstrate with records rather than assert in a meeting.

Three forces pushed it there. Regulators turned security and data protection into statutory duties with real money behind them. Customers and partners began writing independent assurance into their contracts. And the systems themselves grew more automated and more data-hungry, driven by models whose effects reach people who never chose to touch them.

The study works across four surfaces. Lawful is compliance with the regimes that govern data and systems. Secure is the protection of confidentiality, integrity, and availability. Ethical is fairness, transparency, and human oversight, above all over systems that decide about people. Accountable is clear ownership, with evidence for every claim above. Each obligation gets mapped to the controls that satisfy it. A five-level model locates where an organization actually stands, and a phased roadmap closes the piece.

Four numbers set the stakes. GDPR gives 72 hours to notify a supervisory authority of a personal-data breach. The NIST Cybersecurity Framework 2.0 runs on six core functions now, with Govern added alongside the original Identify, Protect, Detect, Respond, and Recover. ISO/IEC 27001:2022 carries 93 Annex A controls across four themes. And the most serious GDPR fines reach 4 percent of a company's global annual turnover, which at the scale of a large firm is a number that changes how a board behaves.

One test runs under every section. Can you show it. A policy nobody follows, a control nobody tests, and a risk nobody owns are, for compliance purposes, the same as having none. Responsibility is whatever survives an audit, an incident, and a regulator's question.

1. What technology responsibility means

Technology responsibility is the organization's accountability for the whole life of the systems and data it controls. It runs from design and procurement through daily operation, and on to the day a system is retired and its disks are wiped. It runs wider than IT security and wider than privacy. It is the duty of care owed to everyone the technology touches, including people who never chose to interact with it.

The duty rests on four surfaces that interlock. None of them stands alone. Regulators and courts generally treat a failure on any one as a failure of the whole.

Figure 1. The four surfaces of technology responsibility.

Five principles hold the surfaces together. The first is duty of care: the organization answers for the foreseeable harms its technology enables, whether or not it profits from them. The second is protection built in from the first design decision rather than bolted on before launch. That principle is now written into law under GDPR Article 25, and into the standards beside it. The third is proportionality, where controls match the sensitivity of the data and the severity of the risk, so there is no single correct spend, only a defensible one. The fourth is demonstrability. The evidence, the records and logs and test results and sign-offs, should fall out of operating the system rather than get reconstructed under pressure. The fifth is that assurance is continuous, because a control that passed last quarter is not a control that works today.

2. The regulatory landscape

No single law defines technology responsibility. A lattice of overlapping regimes sets the obligations instead, some statutory, some sectoral, some voluntary in name and expected in practice. What follows maps the instruments most organizations meet, what each one governs, and the enforcement behind it. What applies to you depends on where you operate, what sector you sit in, and whose data you hold, so read the table as a map and not a checklist.

Figure 2. Principal regimes and standards.

Frameworks and standards are how the law gets operationalized. A firm rarely maps its work to GDPR articles one by one. It runs an ISO 27001 information security management system, or a NIST CSF program, whose controls once in place satisfy the statutory duties. Then it evidences those controls through a SOC 2 report or an ISO certificate that customers and regulators already accept. Build the control once, and map it to many obligations.

A handful of duties recur across nearly every regime:

Breach notification runs on a clock, and it triggers more penalties than any other single failure. Section 9 covers the clocks.

Records of processing, and the asset and data inventories behind them, matter because nothing you have not catalogued can be protected or reported on.

Data-subject and consumer rights, meaning access and correction and deletion and portability and opt-out, come due on statutory timelines.

Vendor flow-down passes your obligations to processors and sub-processors by contract, which section 8 takes up.

Governance evidence means named accountability, board oversight, and decisions somebody actually wrote down.

3. Security obligations

Security is the surface most people mean when they say responsibility, and it has the clearest control catalogue. The aim is old: protect the confidentiality, integrity, and availability of information. The modern version adds two demands on top. Protection has to be designed in, and it has to be verified continuously. NIST CSF 2.0 sorts the work into six functions, and the addition of Govern in 2024 said out loud that security is a management job and not only a technical one.

Figure 3. NIST CSF 2.0 functions and representative obligations.

Several controls are simply not optional:

Identity comes first. Use strong, phishing-resistant multi-factor authentication, grant least privilege, and recertify access on a schedule, because most breaches begin at the login.

Encrypt data in transit over TLS and at rest with managed keys and a defined rotation. Encryption is also the most reliable safe harbor from breach-notification duties.

Manage vulnerabilities continuously. Scan, rank remediation by risk with real deadlines, and put every change through change control.

Build security into the development lifecycle through threat modeling, code review, dependency and secrets scanning, and a software bill of materials so a supply-chain flaw can be traced.

Log and monitor with tamper-evident, centralized collection and detections tuned to real threats, since those logs are the raw material for both detection and response.

Stay resilient with tested backups and disaster recovery, each carrying a defined recovery-time and recovery-point objective.

Regulators increasingly treat secure-by-design as the standard of care and not an aspiration. In practice that means default-deny configurations, a minimized attack surface, memory-safe choices where they are available, and the elimination of whole vulnerability classes rather than the patching of one bug at a time. After an incident, the question used to be whether you responded well. Now it also asks whether the failure was foreseeable and could have been designed out.

4. Data protection and privacy

Privacy is where technology responsibility meets a person most directly. The governing idea across regimes is data minimization with purpose limitation. Collect only what a specific, disclosed purpose needs, keep it only while that purpose lasts, and let people exercise rights over it. Security keeps data from attackers. Privacy governs what the organization itself is allowed to do with the data.

The data lifecycle is a control surface in its own right:

Collect with a lawful basis, clear notice, and no more than the purpose needs.

Use it only for the stated purpose, since a new use needs a fresh basis and often a fresh assessment.

Store it classified, access-controlled, encrypted, and aware of where it sits for transfer rules.

Share it under contract through data processing agreements, with a valid transfer mechanism for anything crossing a border.

Retain it to a written schedule rather than indefinitely, just in case.

Dispose of it verifiably, by deletion or anonymization, at the end of its life.

The obligations that carry the most enforcement weight cluster in a few places. Individual rights come first, meaning access, rectification, erasure, portability, and objection, each fulfilled inside a statutory window, generally one month under GDPR and 45 days under CPRA. Data protection impact assessments come next, required before high-risk processing, and they are the documented record that a risk was weighed before the fact and not after. Cross-border transfer needs a valid mechanism for every flow of personal data across jurisdictions, whether an adequacy decision, standard contractual clauses, or an approved framework. Consent and preference management has to be freely given, specific, and as easy to withdraw as to grant. And privacy by design and by default, written into GDPR Article 25, makes the least-invasive setting the starting default rather than an option buried three menus deep.

A system can be airtight and still break the law. It might collect more than its purpose warrants, hold data past its schedule, or repurpose it with no basis. Treating privacy as a subset of security is a common and expensive category error. The two share controls and answer different questions. Security asks who may touch this data. Privacy asks whether the organization should be holding it at all.

5. Responsible and ethical technology

The newest surface, and the one moving fastest, is about what happens when systems decide, rank, recommend, and generate. Most of that is AI. The EU AI Act is the first comprehensive statute on it, and its shape is worth studying. It regulates by risk tier rather than by the technology itself, an approach other jurisdictions are drifting toward.

Figure 4. EU AI Act risk tiers.

The principles of responsible technology come down to a handful of demands. Fairness means testing for and mitigating discriminatory outcomes across protected groups, and documenting the trade-offs made along the way. Transparency and explainability mean a person affected by an automated decision can learn that it was automated and understand what it rested on. Human oversight means someone can review, override, or halt a consequential decision, with meaningful control and not a rubber stamp. Accountability for outcomes means a named owner answers for a model's real-world effects, including the drift that shows up after deployment. Data governance for AI means training data is documented for provenance, quality, and representativeness, because a model is only as responsible as its inputs. Accessibility and inclusion mean meeting recognized standards such as WCAG, so the system serves people with disabilities and not only the median user. And sustainability means the energy and material footprint of infrastructure and model training is measured and managed as part of the cost of running a system.

ISO/IEC 42001 gives this surface a management-system spine, much as 27001 does for security: governance, risk assessment, lifecycle controls, and continual improvement, all aimed at AI. Adopting it early is the most credible way to show an AI program is governed rather than improvised.

6. Sector deep-dive: healthcare and life sciences

Healthcare is the most densely regulated technology environment there is. Three families of obligation, data protection, payment security, and product safety, land on the same systems and often the same record. A single patient visit throws off ordinary personal data, protected health information, and a payment, and each one answers to a different regime with its own penalties and its own clock. Getting healthcare technology right starts with telling those data classes apart.

Figure 5. Health-data classes and the regimes that attach to them.

A single billing form can carry PII, PHI, and cardholder data at once. That one form triggers GDPR or state law, HIPAA, and PCI DSS simultaneously, each with a different notification clock and a different penalty regime. Classifying data at the field level, not the system level, is the control that keeps those obligations from colliding.

HIPAA binds covered entities, meaning providers, health plans, and clearinghouses, and since HITECH it binds their business associates too, meaning any vendor that creates, receives, maintains, or transmits PHI on their behalf. It works through three rules and the statutes that sharpened them. The Privacy Rule governs permitted uses and disclosures of PHI, the minimum-necessary principle, and a patient's right to reach their own records. The Security Rule requires administrative, physical, and technical safeguards for ePHI, with encryption named as an addressable, risk-justified safeguard. The Breach Notification Rule requires notice to affected individuals and to HHS within 60 days of discovery, plus media notice for large breaches. Breaches under 500 individuals may be logged and reported annually. The HITECH Act of 2009 and the Omnibus Rule of 2013 made business associates directly liable, raised penalties into culpability-based tiers, and created the breach-notification duty. And the Business Associate Agreement is the mandatory contract that flows HIPAA obligations to every vendor that touches PHI, whether cloud, SaaS, or analytics. No BAA, no lawful sharing.

Penalties run in tiers by culpability, from unknowing to willful neglect, with per-violation and annual caps and criminal exposure for knowing wrongful disclosure. That last exposure is why HIPAA sits on the board's risk register and not in an IT footnote.

FDA and connected-device cybersecurity

When the technology is itself the medical device, whether software as a medical device or firmware inside a connected monitor or pump, responsibility reaches into product-safety law under the FDA. The landscape shifted materially in 2023:

FD&C Act §524B, enacted in 2023, requires manufacturers of cyber devices to submit, at premarket, a plan to monitor and remediate postmarket vulnerabilities, evidence of secure design and a patch process, and a software bill of materials. The FDA can refuse to accept a submission that lacks these.

Premarket and postmarket cybersecurity guidance sets secure-by-design expectations before clearance, and coordinated vulnerability disclosure and patching after.

Software intended for a medical purpose is regulated by risk and cleared through the 510(k), De Novo, or PMA routes.

Design controls under 21 CFR Part 820 now harmonize to ISO 13485 under the Quality Management System Regulation.

The EU Medical Device Regulation carries analogous cybersecurity expectations for devices sold in the EU.

Life-sciences records and data integrity

Systems that support regulated manufacturing and clinical work, the world of good manufacturing, laboratory, and clinical practice, answer to their own regime for electronic records:

21 CFR Part 11 makes electronic records and signatures trustworthy and equal to paper, which requires validated systems, secure audit trails, access controls, and signature binding.

Computer system validation under GAMP 5 or CSA gives risk-based assurance that a system does what it should and nothing it should not.

Data integrity follows ALCOA+, meaning data that is attributable, legible, contemporaneous, original, and accurate, plus complete, consistent, enduring, and available.

Figure 6. Additional healthcare and life-sciences instruments.

In healthcare, the question of whether you can show it gets sharper. Can you produce the BAA for every vendor touching PHI, the software bill of materials for every cyber device, the audit trail for every regulated record, and the field-level classification that tells PHI from PII from cardholder data. Each of those is a specific artifact that a specific regulator can walk in and demand.

7. Governance and accountability

Every obligation above falls apart without an owner. Governance is the structure that hands out responsibility, sets the risk appetite, and holds the organization to its own policies. Regulators have made it personal. NIS2 and the EU AI Act attach liability to the management body, and SEC rules force disclosure of how the board oversees cyber risk. "The system failed" has stopped being an acceptable answer. The question now is who was accountable for it.

Governance runs on three lines of defense. The first line is ownership: the teams that build and run technology own their risks and their controls day to day. The second line is oversight: risk, compliance, and security functions set policy, challenge the first line, and monitor it. The third line is assurance: internal audit independently tests that the first two lines actually work, and reports to the board.

The structure is expressed as a cascade, each level more specific than the one above it. A board-level policy states intent and appetite. Standards set mandatory requirements. Procedures give step-by-step instructions. Guidelines offer recommended practice. Auditors trace a control from the procedure that performs it up to the policy that requires it, and a broken link anywhere in that chain is a finding.

The practical test of governance is a short list an executive can produce on demand. Who owns each material technology risk. What is the risk appetite. When did the board last review it, and what changed as a result. If that list cannot be produced quickly, the governance exists on paper and nowhere else.

8. Risk and third-party management

Responsibility gets exercised through risk management. That is the plain discipline of naming what could go wrong, judging how likely and how damaging it would be, and then deciding on purpose what to do. The decision is always one of four. Treat the risk by adding controls, tolerate it within appetite, transfer it through insurance or contract, or terminate the activity that creates it. Regulators do not require zero risk. They require a documented, defensible choice among those four.

That discipline runs on one maintained register of technology risks, each entry carrying an owner, a rating, and a treatment status. The four treatment options are each an explicit, recorded decision rather than a default. And a large and growing share of breaches trace back to third parties, which is why vendor risk has become a first-order duty rather than a procurement afterthought.

Your responsibility does not end at your own perimeter. Regimes from GDPR, with its processor obligations, to DORA, with its ICT third-party rules, to NIS2, with its supply-chain security duties, make an organization answerable for the vendors it leans on. A defensible program covers the full vendor life. Due diligence comes before onboarding, and it looks at security posture, certifications such as SOC 2 and ISO 27001, and financial stability. Contractual flow-down puts the obligations in writing: data processing agreements, security requirements, audit rights, breach-notification clauses, and limits on sub-processors. Ongoing monitoring reassesses on a risk-based cadence rather than once at signing. And concentration planning means knowing where a single cloud or SaaS dependency creates systemic risk, and holding an exit plan for it, which is a particular focus of DORA.

9. Incident response and resilience

Every organization will have an incident. Responsibility shows in how ready it was for one. Two obligations run at the same time when something goes wrong. Respond and recover on the operational side, and notify the parties the law names, on the clock. Those clocks are unforgiving and they vary by regime, and missing one is its own violation, separate from the incident that set it off.

Figure 7. Representative breach and incident notification clocks.

The response lifecycle moves through five stages. Preparation means an IR plan with named roles, runbooks, contacts, and legal counsel lined up in advance. Detection and analysis confirm, scope, and classify the event, and the classification often starts the notification clock. Containment, eradication, and recovery limit the spread, remove the cause, and restore from tested backups. Notification reaches regulators, affected people, customers, and insurers as each obligation requires. And the last stage, learning, runs a blameless review that ends in changed controls rather than a filed report.

A plan nobody has exercised is a hypothesis. Regular tabletop exercises and recovery tests are what turn the document into a capability, and they are increasingly what auditors and cyber-insurers ask to see. Test the clock too. The first 24 hours of a real breach are the wrong moment to work out who is allowed to declare that materiality has been reached.

10. Assurance and continuous compliance

Assurance is how responsibility gets proven, to a board, a customer, an auditor, or a regulator. The shift underway is from point-in-time assurance, an annual audit or a snapshot, to continuous assurance, where controls are monitored and evidenced automatically all year. The reason is plain. Attackers and change do not wait for the audit window.

Figure 8. Forms of assurance and what they demonstrate.

Good evidence has a few properties worth naming. It is automatic rather than artisanal, produced as a by-product of the system through logs, tickets, and pipeline records, and never gathered as screenshots the week before an audit. It is complete and time-stamped, covering the whole period under review with integrity you can defend. It is traceable, so each control links to the obligation it satisfies and the risk it treats, and that crosswalk lets one piece of evidence answer many auditors. And it is honest about gaps, because a known, owned, remediating gap is defensible while a hidden one is not. Surfacing an unknown beats a false assurance every time.

11. A maturity model

Responsibility runs along a path, from ad-hoc reaction to continuous, measured discipline. The five levels below adapt the familiar capability-maturity pattern, and they let an organization place itself honestly and pick the next rung as a goal.

Most organizations overrate themselves. A cleaner calibration: you are at a level only if you can show it, with the evidence for every claim produced without a special project. The goal is rarely L5 everywhere. It is L3 to L4 held consistently, with L5 kept for the highest-risk systems.

12. Recommendations

The path to defensible technology responsibility runs in order, foundations before optimization. The four phases below assume a mid-maturity organization aiming for a consistent, evidence-backed L3 to L4.

Phase 1, foundations, 0 to 90 days: know what you have and who owns it

Stand up the asset and data inventory, name accountable owners for each material system and risk, and adopt one control framework, either NIST CSF or ISO 27001, as the organizing spine. Establish the risk register and the policy hierarchy. Confirm your breach-notification obligations, and confirm who is allowed to declare an incident.

Phase 2, controls, 3 to 9 months: close the non-negotiables

Put in the security baseline: MFA everywhere, least privilege, encryption, patch deadlines, centralized logging, tested backups. Stand up the vendor-risk lifecycle with contractual flow-down. Run impact assessments on high-risk processing and build the machinery that fulfills data-subject rights. Exercise the incident plan with a tabletop.

Phase 3, assurance, 6 to 18 months: prove it, and pursue attestation

Map controls to obligations in a reusable crosswalk. Pursue SOC 2 Type II or ISO 27001 certification. Move evidence collection from manual to automated. Establish AI governance, an ISO 42001 posture and risk-tiering of AI systems, ahead of the obligation to have it.

Phase 4, continuous, ongoing: make responsibility a standing discipline

Run continuous control monitoring, carry metrics to the board, hold blameless post-incident reviews that feed control changes, and reassess every year against a regulatory map that keeps moving.

The whole roadmap serves one moment. The phone rings, and the regulator asks who owned the risk, what treated it, and where the proof is. An organization that has done the work answers in a few sentences and reaches for the records. The one that has not spends the next 72 hours discovering what it cannot show.

13. Glossary

Technology Responsibility: A Compliance and Security Study. Version 1.0, 2026-07-20. Prepared as a general reference by Jason Newell. This study is educational and does not constitute legal advice. Obligations depend on jurisdiction, sector, and the specifics of the data and systems involved. Regulatory details, including thresholds, deadlines, and phase-in dates, reflect the regimes as understood at the date of issue and should be confirmed against current sources before action. Named frameworks and standards are the property of their respective bodies.