Thursday, June 16, 2026
Overview
In a June 16, 2026 webcast for the Berkeley Center for Law and Technology, Professor Chris Hoofnagle explained how the EU Cyber Resilience Act (CRA), effective December 2027, imposes a comprehensive product-liability and software-safety regime on Internet of Things devices and standalone software sold in Europe. The single most important takeaway: American technology companies that have not yet begun CRA compliance planning are already behind schedule, because meeting the Act’s security-by-design mandate requires front-loading security into the earliest stages of the product development cycle.
Instructor(s)
Chris Hoofnagle, Professor of Law and Faculty Director, BCLT, UC Berkeley School of Law
Keywords
EU Cyber Resilience Act (CRA) 2024 compliance • product liability software cybersecurity Europe • Internet of Things security regulation EU • Brussels Effect cybersecurity law • ENISA vulnerability disclosure requirement • security by design product liability • Lemmon v. Snap, Inc. software products liability • General Data Protection Regulation (GDPR) enforcement comparison • how does the EU Cyber Resilience Act affect US software companies • what does the EU Cyber Resilience Act require manufacturers to do • CRA IoT device risk classification Class I Class II • EU cybersecurity essential requirements Annex I
Key Takeaways
- December 2027 deadline is imminent. The CRA takes full effect in December 2027, and Hoofnagle warned that “in order to comply with this in their next product cycle, [clients] are going to have to start thinking about it now.”
- Software is now a product in Europe. The CRA extends product-liability obligations to standalone software, APIs, and firmware—not merely physical IoT hardware—meaning virtually every connected application sold into the EU market is covered.
- Class I will capture most consumer IoT. Hoofnagle predicted that most connected consumer devices—smart locks, cameras, routers, wearables, VPNs, virtual assistants—will fall into Class I, and any feature addition that “touches security” forces reclassification and a full compliance re-run.
- 25+ essential requirements apply universally. Even the lowest-risk default-category devices must satisfy the full Annex I essential-criteria list; Hoofnagle noted that the only device he identified as plausibly compliant is the Apple iPhone.
- 24-hour ENISA notification for active exploits. Upon discovering an actively exploited vulnerability, manufacturers have 24 hours to notify ENISA and, if consumers may be harmed, must issue separate consumer-facing disclosures.
- Enforcement will target U.S. companies first. Hoofnagle predicted that enforcement actions, when they come, “will be against American companies, in part because America is where things are invented”—making Silicon Valley emerging-company clients particularly exposed.
- Agile development is incompatible with the CRA. The CRA’s security-by-design mandate requires front-loaded risk assessment before product conception, effectively moving clients from agile “towards a waterfall environment” and making the minimum-viable-product model legally risky.
- California tort defaults now travel to Europe. European regulators are deliberately importing California-style products-liability standards—shifted causation burdens, expanded cognizable injuries, and class-action mechanics—into the EU framework.
- The Snap Case settled the software-as-product question. Lemmon v. Snap, Inc. resolved the prior uncertainty about whether software is a “service” or “product” for liability purposes, opening U.S. courts to the same product-liability theories the CRA codifies.
- The science of secure software remains unsettled. Hoofnagle cautioned that the CRA’s regulatory ambition may outpace available knowledge: “no one can show that [compliance with a security standard] actually reduces breaches,” suggesting the law may impose costs without a demonstrated reduction in risk.
B-CLE Recording (CLE: Free) | Youtube Recording | Resource(s) | Speaker Bio(s) & Contact Info
Download the interview/transcript and slides here!
Interview/Transcript
This interview/transcript was based on a conversation held on June 16, 2026 about Europe’s Cyber Resilience Act. In this program, Berkeley Law Professor Chris Hoofnagle breaks down the CRA’s essential cybersecurity requirements, risk classification tiers, mandatory vulnerability disclosure duties, and five-year support lifecycle obligations.
Wayne Stacy 00:25
So welcome everyone to this week’s session webcast with the Berkeley Center for Law and Technology. This is always a highlight of any of my recordings, is when I get to work with faculty co-directors here at Berkeley Law. So today we have Professor Chris Hoofnagle with us. Professor Hoofnagle is got a long, long series of titles, and he deserves a lot longer series of titles, but he’s faculty director for the Berkeley Center for Law and Technology and Professor of Law here at Berkeley Law. He leads so many of our technology courses, from, hardcore Python type courses to leading our cyber security initiatives here at the university, so it’s always a pleasure to hear from Chris. What he has for us today is a topic that it’s hard to stump me completely when he sent over this topic, I’d never heard of it, and now that I’ve heard of it, I can’t get out of my mind why I haven’t heard of it, and I think that’s something that should scare all of you, that if you haven’t heard of the CRA, which my bet is you haven’t, this will be a pretty enlightening 30-40 minutes for you. So, with that, Chris. Thank you, and I’ll turn it over to you.
Chris Hoofnagle 01:45
Thank you, Wayne. And I think you nailed it. This talk is about a cybersecurity framework that is emerging from Europe that has been obscured by the AI Act [Artificial Intelligence Act] and the DSA [Digital Services Act], all these other things, all these other compliance duties that we’ve been concerned about, so I’m writing a paper about this framework with Lothar Determann, who is a Berkeley Center for Law and Technology [BCLT] partner and who teaches here at Berkeley. And just so you know, why should you pay attention to this presentation? I thought I’d give you a bottom line up front. The bottom line up front is that Europe has created a products liability doctrine to deal with security, and it takes effect in December 2027. So, if your clients haven’t heard about this, they have to start thinking about it, because in order to comply with this in their next product cycle, they’re going to have to start thinking about it now. So, that’s the bottom line up front. Let me pan out a little bit, and explain what’s happening in Europe. In Europe, information security is becoming a human right, so just like privacy before it, but is now considered a human right, and carries with it all the obligations and strengths of a right, data security is becoming a right, and some European academics, such as Lee Bygrave, has been making this point in the literature, telling us, “Watch out, this new right has been established.” How is this being articulated in the Cyber Resilience Act, which I’ll call the CRA, for Cyber Resilience Act. The Cyber Resilience Act is a products liability approach to cybersecurity. It’s essentially going to make all Internet of Things devices and even standalone software subject to a product liability flavored legal regime. So it’s not just privacy, it’s not just security breach notification, this is a safety law for software, software safety, if you will, and it’s not software safety in the sense that, like, your car has to be safe, so it doesn’t run over pedestrians, or the brakes don’t work. The concept of safety is much broader, and it includes mental injuries, such as what were to happen if the data from my connected doorbell were to leak on the internet. So, how did we get here? Lot of big picture dynamics in play. One is what’s known as the Brussels Effect. This is the idea that regulators in Brussels have realized that when they pass rules, the whole world complies with them. GDPR [General Data Protection Regulation] is a great example of this, but there’s other examples where, in essence, Brussels is regulating the world. The other issue I alluded to earlier, privacy before it, and now security is becoming a fundamental human right in the European human rights framework, so the European Court of Justice has made findings declaring that there is a duty of data security, security, and it’s not vested in statute, it’s vested in human rights. There’s a whole bunch of security issues at play here. What I’ll call securitization, not in the sense of financial instruments, but securitization in the sense of international relations theory. This is the idea that cybersecurity is now seen as a national security issue. Increasingly, Europeans are concerned that the devices they are using may be commandeered by the Russians, and used to attack them. Europe is in a tough security position right now, with a stagnating economy, with populism on the rise, and the problem of Russia aggression in Ukraine. Europeans are worried that they might experience aggression through cyber means, and there’s good evidence to believe that they are correct in this couple other things that are happening too. There’s parallel instruments that are very strong that are amping up consumer protection in Europe. Europe has new directives on products liability and safety, and those all come together in security. And then finally, the consumer, the Cyber Resilience Act is presented as a risk-based regulation. However, when you read it, there really is very little risk tolerance in it. It is a kind of everything bagel approach, where even the lowest risk devices are treated as high risk in a way. So, how did we get here? Europe announced a long time ago that they were going to pass regulations of different areas of technology. They started early in the 2000s saying that they were going to develop a common approach to cyber security. They created an agency in 2004 it’s known as ENISA. The acronym has changed over time. In 2013 they introduced a cyber strategy, and that cyber strategy said we’re going to pass cyber laws, we’re going to regulate ICT [Information and Communications Technology], we’re going to regulate banks, we’re going to regulate critical infrastructures, and then the next years they do that, they pass NIS1, they pass the Cyber Act, strengthening ENISA, and then they pass the DORA [Digital Operational Resilience Act]. Now, you’ve probably heard of the DORA, this is the law that regulates cybersecurity of banks in Europe, and it’s probably the most prominent cybersecurity instrument, but by 2022, there was something strange about this, the Europeans had regulated everything but consumer products, and that’s the Cyber Resilience Act, that it basically, there was like a glaring hole in the regulatory universe here. Why is everything regulated, but the aside from these Internet of Things devices that are all around our houses, and so that’s what the CRA does. It becomes effective in December 27, 2027 typically, it has fines that are typical of a lot of European instruments. It’s $15 million or 2.5% of worldwide turnover. It regulates products with digital elements. A shorthand way of thinking this is Internet of Things. Basically, anything that connects to a network is covered by this regulation, and that’s true with respect to consumer gadgets, like literally the $10 consumer gadget that you buy to business gadgets, so this same regulation regulates the low end and the high end, if your business were to buy $100,000 network appliance from, let’s say, Cisco or Juniper, that would be protected by the CRA as well. So it’s interesting, the CRA is both a consumer protection and a business to business protection law, and of course, because it’s products liability. What it does is it creates a chain of accountability. The manufacturer is responsible for many elements of the CRA, but importers and retailers are responsible as well. So to create the chain of a kind of accountability importers are supposed to look at the manufacturer’s IoT device and see whether it has been certified, and it has the CE marking, and you’re probably familiar with the CE marking. It’s basically on every product, any product you pick up in front of you right now. If you look at it close enough, you’ll see the European CE mark on it. It’s an example of the Brussels Effect, the idea that Europe has basically been able to push consumer regulations on almost all products, even products that are not in Europe. So, the idea is the importer shouldn’t import unless they see that CE, and that’s the, that’s the accountability mechanism. So, what does the CRA require? It requires security by design. What this means, if you read the act literally, is that when a company conceives of a product, they should be thinking about security. So, in the very beginning, you know, as soon as you’re thinking about a problem in the world and a product or service to deal with it, you should be thinking about the security elements. Should also, when that product is created, it should have security by default, encryption should be on, strong password should be on, and so on by default. The law also requires manufacturers to think about the lifecycle accountability of their product. Basically, they have to declare how long the product is going to work. The default term is five years. So, suppose you go to, let’s say, the Home Depot, and you pick up the connected lock, right, the electronic lock that connects to the internet, and so on. That package will have to have a disclosure on it that says how many years the manufacturer will support the software in it with updates and the like, and the default is five years. And, of course, the manufacturer can say more or less; they just have to be reasonable about their statement. Of course, this means something for planning, and most of our clients are probably in the agile software development market model, where it’s much more flexible. You deal with problems as they come up, you adopt new goals as your product develops. This law basically moves us more towards a waterfall environment where you have to do more planning at the front end to make sense to comply with with the law, and this is explicit in the CRA. The CRA says you have to think about security when you design, when you conceptualize the product, you can’t bolt it on later. So, I talked about the idea that this is a risk-based regulation, but when you look at the details, really, it isn’t. It, like a lot of European instruments, it treats almost everything as high risk, so what the law does, and one of the things we’ll have to do as lawyers is talk our clients through the risk assessment of their products. There are four tiers. At the highest tier are things like critical infrastructures, they’re already regulated, we know, we know to think about security when you are giving advice to some type of system that exists inside a hydroelectric plant or a telecommunication station, that’s fine. The next most sensitive is what’s known as Class Two important. Now, these are devices that control security of other devices, so an example would be a firewall, a company that makes virtual machines, a company that does identity provision. So, who’s in class two important? Well, those are companies like Microsoft and Google, and let’s say the Cloudflares of the world, and the Ciscos and the Junipers of the world, I think, probably most people listening to this, their products will actually be in what’s called Class One important, and this is where most, most of, I think, are useful IoT devices are. They’re things like the lock on your front door that’s connected to the internet, your smart speaker, pretty much anything that you touch that somehow controls the security of something else, like your front door. Even security cameras, you know, security cameras that merely view the an area are considered class one important. And then finally, there is a category that it doesn’t actually have a name, it might just be called default or unimportant even. These are for devices that truly are trivial. An example would be a smart, excuse me, an example would be a speaker that you connect to the internet that doesn’t do anything else, it doesn’t have Alexa, doesn’t have Siri, doesn’t have AI, it just connects to your network and plays Music, that would be in the lowest risk risk threshold, but to be clear, if your client made that speaker and then you added something to it, let’s say you added Alexa to it, it gets upgraded to class one important, and then you have to redo all your legal work and certification work surrounding the device. So, I think most class, most devices, most people in the consumer market will be class one important devices. There’s some language in the regulation that’s very confusing, some language. Which, in the regulation, says, well, if your device processes personal information, it’s actually in class two high risk, that is. But read that in context, that language really is for enterprise level devices that process personal information, enterprise routers, enterprise firewalls, and so on. It doesn’t apply to, let’s say, the router in one’s home, or even in one’s office. So you have your four risk tiers. What do you have to do? Well, our clients are going to have to ensure reasonable adherence to a list of essential criteria. These are published in the regulation. They are in the annex. It’s annex one, so you can just, you can just read it. I spent a lot of time looking at this, and the I see when I, when I read the list, I see 25 separate requirements, but many of those requirements have sub requirements, meaning that this is not trivial, and what I pan out, and I look at this list, and I ask myself, what, what connected devices are likely in compliance with this, really the only, the only one I can come up with is the Apple iPhone. I, the, this is a, this is kind of a security dream scenario to do all these things. Some of them might not be theoretically possible to comply with perfectly, so this is going to be an area where we have to use our reasonableness arguments to make sense of what our clients need to do and the things that are simply good enough, so because the motivating logic of this framework is securitization, because it at core, what the Europeans are thinking about is national security. This regulation really isn’t a risk regulation. It treats even low-tier products as sensitive, and even the lowest tier object still has to comply with the whole essential cybersecurity list. That’s literally essential, as in baseline cybersecurity. The CRA expects you to go beyond that baseline in some circumstances. So, what this means, like one of the great upsides of this approach is, is that you’ve probably been reading in the newspaper about various internet of things devices that have back doors. These are the kind of the really cheap devices that often come out of China. Those devices are simply banned by the CRA. You can’t have a back door and, and a device, and so we might see those devices starting to disappear from the marketplace, so we have risk scoring, we have essential cybersecurity criteria. How do you prove that you have complied with the cybersecurity criteria? Well, you have to do certifications. Now the good news is, and this is where we do see some risk bought coming out of Brussels. A lot of clients will be able to self certify. It depends on how risky their products are, but I think most Internet of Things products are going to be in this class one. Products in Class One can self certify, so long as they use an instrument that’s harmonized and approved by the EU, for other entities they’re going to have to hire an outside company to do that certification. I checked just the other day, and there are no certifiers certified to do this work yet, so this is still something that needs to be worked on, but presumably companies are going to be are going to start to emerge from Europe that offer this service, this certification service of products. Another duty of Internet of things products and a software is the duty to give vulnerabilities disclosures, and this looks a lot like security breach, but it’s not. It’s vulnerability disclosure that that is when your client learns that there is a bug in their software that can be exploited, they have to tell the regulator, so within, and actually they might have to do it very quickly if it’s actively exploited. So, if your security engineer calls you one day and says, I’m very sorry to tell you this, but we found a bug in this library, and someone’s broken into our software, within 24 hours you have to file a notice of active exploit with ENISA. Now, if it’s a severe incident, that is, if it could implicate consumers, if it could hurt consumers, you also have to give that notice to your end user consumers. So, I think there’s a lot of really interesting lawyering that can happen around this law. What are those issues? Well, we need to help our clients categorize their device, their devices on risk level. We have to help our clients think through the intended use of their product. If let’s say I give the example earlier, if you have a connected speaker and all it does is play music, that’s great, it’s a so-called default device. But let’s say your engineers call up and say we figured out how to add Amazon Alexa. Well, that’s a new use, and so you’ll have to do a new assessment under Class One, the higher level assessment than that, then earlier. You also have to think about your product lifetime, and of course, clients, clients are going to want to say this product is going to work forever, it’s going to serve, it’s going to solve all your problems, it’s gonna make all your dreams come true. Well, in the CRA universe, you can’t do that. You’re going to have to say we expect this product to last N years, and then you’re going to have to support it. You’re going to have your client is going to have to commit to providing security upgrades, monitoring the security, and so on for that product, so that means some really interesting implications, including the idea that you might want to stop selling certain products, you might even pull products from the marketplace because you don’t want to deal with ultra long support periods, so some key takeaways, and I’m nearing my end here. One is on enforcement. The regulators in Europe are way behind on enforcement; they can’t keep up, even with the GDPR. CRA as is a significantly expanded and complex regulation. I don’t think Europe is going to be ready to enforce this anytime soon. One reason for that is it’s not just my opinion, it’s if you look at ENISA itself. ENISA is in Athens, Greece now, it has a $44 million budget, and just 113 employees. That’s not big enough to regulate all the products in the world. You think about the FDA, the Food and Drug Administration in the United States, it has a $4 billion budget. I think in order to really to contemplate regulating the world software, we’re going to need a much larger and more sophisticated agency, and this agency has lots and lots and lots of statutory duties, which are going to make enforcement complex, so my big lesson here is, don’t panic. We’re not going to see enforcement actions on day one when this takes effect in December 2027. There’s a lot of implications surrounding the game theory of innovation. We all know, as Silicon Valley lawyers, we all know that you really want to be first to market, first to market with your MVP [minimum viable product]. That gets complexified in a world with CRA. CRA demands, as I mentioned before, that security is in there by default. You can’t ship security in version two or version three, as what often happens with our clients. So, one question is, will our American clients innovate differently? Will they make choices about Europe that are different, so that they can get to market faster. Can you opt out? Yes, your clients can make products, just don’t sell them into the EU. Now, does that mean that they’re not in the EU? No, importers could find your product and say, you know what, Europeans really want this, and they could risk it. The importers could end up holding the liability for bringing those products into Europe, but a key way to gain some time here is simply to avoid the European marketplace until one can earn that CE label with all the certifications and security requirements satisfied. I mentioned at the very outset that this is a products liability regulation. I teach torts here, so I think a lot about products liability. One of the things that’s happening in Europe is that they’re looking at American class actions and saying to themselves, I think we want this here. I’m not sure that’s a great idea, but a lot of people are thinking that, and when Europe looks to America and asks what torts should we copy, they tend to copy California style torts, and as all of you know, California product liability is very plaintiff friendly. There are several defaults that are assigned to defendants, so for instance, the burden of causation is lessened when it comes to products liability in California, and so when we see regulation, when we see this regulation coming out of Brussels, what we are seeing is reflected back is the California tort system with its pro plaintiff defaults. What we’re also seeing in California Torts, the kind of real politic is that defendants are settling cases because of the feeling that juries will run away with huge verdicts, and if you just look at recent cases concerning LLMs [large language models] and people who have been harmed by LLMs, a lot of those cases are settling because they don’t want to go in front of juries, and I think that’s a, it’s a natural consequence of using a product’s liability approach for software with all of its defaults so attuned to be plaintiff friendly. So this is it, and I’ll just wrap up. I want to put this law on your on your agenda, so you can start thinking about it when you’re, when you’re talking to clients. December 2027 is not far away. Our clients have to be thinking about this law now to comply with it then. This is going to be complex, and I think one place to start is by sitting down with those essential criteria and sitting down with your client and asking them what would it take to meaningfully do everything on this list that would be a good first start and it might be that a lot of this they’re already doing so let me let me press escape here and let’s look forward to speaking with Wayne. And, of course, I’ll have, my paper with Lothar will be out before too long. I’m happy to speak with anyone about it.
Wayne Stacy 27:52
Perfect. Well, Chris, I guess my first question is going to be, is Europe really introducing anything beyond kind of what best practices to deal with U.S. tort law already requires.
Chris Hoofnagle 28:08
Well, I think so. Until just a few years ago, plaintiffs were losing cases under product liability theories because defendants could say that software was a service, not a product. Now that was crossed in what’s known as the Snap Case [Lemmon v. Snap, Inc.], now we have a whole lot of platform and software cases being litigated both under regular negligence and consumer products negligence. I think what what’s big here is that we do have a law in California that makes companies liable for so-called unreasonable security breaches, like if you have unreasonably bad security, you can be liable for your security breach, but no one, it’s hard to say exactly what reasonable security is. So I think the real innovation here is that list of essential security requirements, basically Europe is saying this is the baseline, these are the things you should be doing, and if you don’t do these things, you’re not reasonable.
Wayne Stacy 29:29
So recently we saw the kind of the big blow up with Anthropic and the fear that they basically could undermine all cyber security. What do you see in these European regulations going forward on dealing with AI-designed cybersecurity attacks, and how to defend against them?
Chris Hoofnagle 29:51
So, this regulation was written before the LLMs have become so powerful, so it does not anticipate that. However, there is a performance standard in this law. It’s related to security vulnerabilities. So, the very first requirement, and I can read this, is when you release software or an Internet of Things device, a manufacturer is required to make it available on the market without known exploitable vulnerabilities, so that’s a performance standard that requires monitoring, right? And so there are websites out there, they’re called the CVE [Common Vulnerabilities and Exposures] websites, where you can see what vulnerabilities have been declared. The idea is, is that your product has to avoid all of those vulnerabilities, and so, presumably, as Claude or as ChatGPT finds new holes in software, those will be disclosed as known vulnerabilities, some of them will be disclosed, and then clients, security engineers will have to patch those vulnerabilities and push the patch automatically to the consumer.
Wayne Stacy 31:12
Well, it sounds like we’ve got our work cut out for us for a while. Because, I think you mentioned that the point being that, if you’re understaffed, that means you’re selectively enforcing, and I wouldn’t want to be, I wouldn’t want to rely on skipping getting caught, especially if you’re the main manufacturer. So, do you think it really is practical for, especially a US company, to think that they won’t be part of a selective enforcement, especially maybe a bigger, a bigger named US company.
Chris Hoofnagle 31:46
Yeah, I think enforcement is political, and the it’ll be US companies that are first for enforcement. But again, I wouldn’t panic. I don’t think ENISA is going to be prepared to enforce this on in December 2027 that is not far away, but I do think that enforcement will be against American companies, in part because America is where things are invented, so in a way we are the target, and to some extent, Chinese manufacturers are the target too. So, what I found is that most of the lawyers I speak with have never heard of this, and the exception is big manufacturers. They have, they have a beat on this, because they realize that they’re the ones making products, but if you read the regulation, you read the guidance, it’s also going to apply to applications, just pure software applications, for instance, in the app store.
Wayne Stacy 32:55
So for the Silicon Valley crowd that’s doing emerging company work, mid-sized company work. This is probably important for them to really start paying attention to, because, like I said, in that crowd I’ve never heard of, heard of them have this discussion. So seems like they may be the most vulnerable.
Chris Hoofnagle 33:17
And I think you know the thing to do now is to take this one page out of the regulation, it’s annex one, and to send it to the whoever’s in charge of security at your client, and ask them, Where are you on this? I mean, are you 50% in compliance with this or less, and and can you build these benchmarks into what you’re doing? The device is all good, it’s as you read the cybersecurity requirements, you’ll nod your head, and you’ll say to yourself, in a dream world with great security, I want all this, I want all this as a, as a consumer, but it’s going to be a lot of work.
Wayne Stacy 33:56
Well, Chris, I’ll leave you with my final observation, the observations of an old retired patent litigator, which are worth exactly nothing, probably, but you said it to start out with, and I think this is what I would take away from this is that cyber security has come into its own legal realm, that we used to talk about privacy by design, now we have to talk about privacy by design, and separately have to talk about cyber security by design, in whether it’s the CRA or what’s coming in other jurisdictions. These are now two separate areas that everybody needs to focus on and focus on separately.
Chris Hoofnagle 34:39
Yeah, a lot of jobs for lawyers, and what I’d say is, privacy is quite mature. We have an idea of what we need to do in privacy. Privacy is mostly procedural rules that, when implemented, create substantive protections. We actually don’t know what to do in security yet. So, even if you spend lots and lots and lots of money and bringing your, your product into compliance with this security standard or that security standard, no one can show that it actually reduces breaches. So one of the reasons why I’m a bit negative on this law is that I’m not sure that we are ready, I’m not sure that we know how to solve this problem yet, so I don’t think we’re at the maturity level to have such a magisterial set of rules.
Wayne Stacy 35:43
I think that is a perfect way to conclude this recording. What a good piece of advice. So, Chris, thank you for taking the time to share this with us. I know you have other things to do, but this is great. Thank you.
Chris Hoofnagle 35:57
My pleasure. Thank you.
This transcript was created with an automated transcription service and reviewed by a human