Video DRM for OTT Apps: The Security Requirements Studios and Distributors Actually Audit You On

Turning on Widevine and FairPlay is not the same as being ready for a studio security review, and that gap is where most OTT platforms actually fail.

A security team can have both DRM systems correctly integrated and still get flagged, because studios do not audit whether DRM exists. They audit whether it is configured to the specific security level a content tier requires, and a platform that applies the same DRM settings to its SD catalog and its day-one 4K release has already failed that check before the conversation starts.

This has nothing to do with whether Widevine or FairPlay DRM works as technology. It has everything to do with whether device tiering, output protection, watermarking, and documented evidence match what the studio's content protection schedule demands for that title.

This article breaks down what studios and distributors check in a real audit, the evidence they expect you to produce, and the multi-DRM architecture that passes review the first time instead of the third.

---

Key Takeaways

• Studios and distributors audit the full content protection pipeline against frameworks like the MovieLabs Specification for Enhanced Content Protection (ECP), not just whether DRM is switched on.
• A broad OTT service needs multi-DRM: Google Widevine for Android and Chrome, Apple FairPlay for iOS and Safari, and Microsoft PlayReady for Windows and Xbox.
• Premium HD, Full HD, and UHD content typically requires hardware-backed Widevine L1, not software-only L3, plus HDCP output protection enforced at the same tier.
• DRM protects license keys and playback authorization. It does not stop credential sharing, camcorder piracy, or every form of screen capture on its own, which is why forensic watermarking and signed URLs exist as separate layers.
• Auditors expect documented evidence: architecture diagrams, a device support matrix, key management records, and incident response procedures, not a verbal walkthrough.
• Content tier should set security policy. A catalog SD title and a day-one 4K release should not run identical protection settings in the same app.

---

What Do Studios and Distributors Actually Check in an OTT Security Audit?

Studios check whether your DRM configuration, device security tiers, output protection, key management, and evidence trail match the content protection schedule attached to your specific licensing agreement, not whether a DRM toggle is on.

As of 2026, most reviews walk through the MovieLabs Specification for Enhanced Content Protection (ECP), currently at version 1.4, which the six major studios built specifically to define what "protected" means for 4K, HDR, and early-window content distributed over the internet.

MovieLabs ECP defines the technical bar. The Trusted Partner Network (TPN), wholly owned by the Motion Picture Association (MPA), is the assessment process that checks whether a platform actually clears it.

Launched in 2018 by the MPA and the Content Delivery and Security Association, TPN benchmarks a service provider's security posture, covering DRM, key management, and physical, digital, and cloud security, against the MPA's published Content Security Best Practices.

A TPN assessment results in Blue Shield status for a self-attested review or Gold Shield for one independently audited by a TPN-accredited assessor, and studios increasingly ask for a TPN report before they'll trust a platform with pre-release or premium content at all.

A platform can pass every row in the evidence table below and still stall a studio conversation if it has never gone through TPN, because the studio's security team is often checking for TPN status as the first gate, not the last one. 

The specification covers three areas, and auditors work through all three:

1. DRM System Specifications
2. Platform Specifications
3. End-to-End System Specifications

In the early 2020s, a platform could often get by with DRM turned on and a verbal walkthrough of its architecture. That is no longer true.

Studio security teams in 2026 expect documentation on the spot, not a promise to follow up, because the volume of platforms requesting premium content access has grown faster than the volume of security staff available to chase down missing paperwork after the fact.

Gumlet builds video protection infrastructure for SaaS, EdTech, and media platforms that go through exactly this kind of review, so the checklist below comes from what actually gets asked in those conversations, not from a generic DRM explainer.

Independent frameworks like MovieLabs ECP and the Streaming Video Technology Alliance's security checklist point in the same direction.

The Studio Audit Evidence Table

Here's what changes the outcome of a review: having the evidence ready before the auditor asks for it. Most platforms can explain their DRM setup verbally. Few can produce documentation on the spot, and that gap alone stalls or kills reviews that would otherwise pass on the merits.

Audit Area	What the Auditor Checks	Evidence to Produce	Common Failure
DRM configuration	Which DRM systems are active, at what security level, per content tier	Configuration export showing DRM-to-tier mapping	Same security level applied to SD and 4K content
Entitlement	How playback authorization is verified before a license is issued	Entitlement service flow diagram	DRM license issued without a separate authorization check
Encryption	Whether content uses standards-based encryption at rest and in transit	Encryption spec (CENC/CMAF, AES key length)	Proprietary or undocumented encryption scheme
Device security	Whether playback is gated by device security level (Widevine L1/L2/L3)	Device support matrix with security levels per platform	4K served to software-only L3 devices
Output protection	Whether HDCP is enforced for HD/UHD output to external displays	HDCP policy documentation by resolution tier	HDCP not enforced, or enforced inconsistently across platforms
Watermarking	Whether forensic or dynamic watermarking exists for premium/early-window content	Watermarking implementation notes and sample trace	No watermarking on high-value or pre-release titles
Logging	Whether license requests, entitlement checks, and playback events are logged	Sample log schema with timestamp, content ID, DRM result	No centralized logs, or logs missing entitlement outcome
Credential security	How API keys, signing secrets, and DRM credentials are stored and rotated	Key rotation policy and secret storage architecture	Long-lived credentials hardcoded in client apps
Operational controls	Incident response, revocation process, and monitoring for anomalous access	Incident response runbook and revocation procedure	No documented process for a leaked credential or compromised device

The verdict: Platforms that fail on their first review almost never fail because DRM was absent. They fail because one row in this table had no evidence behind it, usually device security tiering or logging, and the auditor had no way to confirm the claim being made verbally.

What Evidence to Have Ready Before the Conversation Starts

Walk into a studio security review with these five documents already assembled:

1. Architecture diagram showing the full path from encoding through DRM license issuance to playback, including where the CDN sits relative to the license server.
2. Device support matrix listing every supported platform, its DRM system, and its security level (L1, L2, L3 for Widevine; equivalent tiers for FairPlay and PlayReady).
3. Encryption and key management documentation covering the encryption standard used, where content keys live, and how license requests are authenticated.
4. Recent penetration test results or, at minimum, a documented internal security review with dates.
5. Incident response procedure describing what happens if a credential leaks, a device is compromised, or content appears on a piracy site.

If your OTT app is protected with Gumlet's video DRM, most of this evidence already exists as configuration data rather than something assembled from scratch.

A platform that can export its DRM-to-device mapping in a single screenshot moves through review faster than one reconstructing the same information from three engineers' memories.

---

Which DRM Systems Does an OTT App Actually Need?

A broad OTT service needs three DRM systems working together:

1. Google Widevine for Android, Chrome, and Android TV
2. Apple FairPlay for iOS, iPadOS, macOS, and Apple TV
3. Microsoft PlayReady for Windows and Xbox

This is called multi-DRM, and it is not optional once your audience spans more than one device ecosystem. No single DRM system is licensed to cover every platform, so a single-DRM app structurally cannot reach the full range of devices a studio expects you to serve.

DRM System	Owner	Platforms Covered	Hardware Security Option	Typical OTT Role
Widevine	Google	Android, Android TV, Chrome, Firefox, many smart TVs	L1 (hardware-backed)	Primary DRM for the largest device footprint
FairPlay Streaming	Apple	iOS, iPadOS, macOS, Safari, Apple TV	Secure Enclave-backed	Mandatory for any Apple device reach
PlayReady	Microsoft	Windows, Xbox, many smart TV and CE platforms	SL3000 (hardware-backed)	Required for Windows and console distribution

Multi-DRM refers to running these three systems in parallel against a single set of encrypted media segments, rather than maintaining separate encrypted copies per platform. Common Encryption (CENC for Widevine and PlayReady, CBCS for FairPlay) makes this possible: one encrypted asset, three license paths.

Ask any vendor pitching single-DRM coverage how they plan to serve iPhone users without FairPlay. There is no workaround. Apple does not license Widevine playback on iOS, and Google does not extend Widevine's hardware security tier to non-Android software players.

If a platform tells you one DRM "covers everything," that claim does not survive contact with a device matrix.

Why Single-DRM Breaks at Scale

Picture a mid-size OTT app with three real audience segments: viewers on Android phones and Chromecast, viewers on iPhones and Apple TV, and a smaller but high-value segment watching on Windows laptops through a browser.

A Widevine-only deployment plays back cleanly for the first group and fails outright for the second and third, because Safari and Apple TV do not support Widevine license acquisition at all.

This is not a configuration problem you can fix later. It is why every OTT platform serving a real cross-device audience runs multi-DRM from day one, and why studio content protection schedules typically name all three systems by requirement rather than leaving DRM choice open.

For a closer breakdown of how the two most contested systems compare on setup complexity and licensing cost, see FairPlay vs. Widevine.

---

What Widevine Security Level Does Premium Content Require?

Widevine has three security levels, and studios do not treat them as interchangeable:

1. L1 performs both decryption and video processing inside a hardware-backed trusted execution environment, and it is what most content protection schedules require for HD, Full HD, and UHD playback.
2. L2 handles cryptographic operations in hardware but processes video in software, a middle tier rarely specified directly in studio agreements.
3. L3 runs entirely in software, with no hardware root of trust, and it is typically capped at SD resolution or lower by the content owner's own policy, not by any technical limit Widevine itself imposes.

The distinction matters because it changes what a device can be trusted to protect. A phone running Widevine L1 keeps the decrypted video frame and the decryption key inside a walled-off hardware region the operating system itself cannot inspect.

A device running L3 decrypts and processes video in regular application memory, which means a compromised OS or a sufficiently motivated attacker has a meaningfully larger attack surface to work with.

Hardware-Backed DRM Explained

Hardware-backed DRM routes the decrypted video frame through a Trusted Execution Environment (TEE), a physically isolated processing region on the device chip that the main operating system cannot read from or write to. The decryption key never leaves this protected region, and neither does the unencrypted frame before it reaches the display output. 

Software-only DRM, by contrast, decrypts inside the normal application process, which means the same memory the OS uses for every other app is briefly holding unprotected video content. 

This is the technical reason studios tie L1 to premium resolution tiers: the protected path exists specifically to keep decrypted content out of memory that debugging tools, malware, or a rooted OS could access.

For a deeper breakdown of DRM by platform type, our guide on DRM setup by platform covers the tradeoffs across OTT, e-learning, and internal video.

---

How Should OTT Apps Handle License Keys and Encryption?

Encryption and DRM solve two different problems, and conflating them is one of the more common gaps auditors flag.

Encryption makes the video file unreadable without a key. DRM controls who receives that key, under what conditions, and for how long.

A platform can have strong AES encryption and still fail a security review if the DRM layer controlling key distribution is weak, because the encryption was never the part being tested.

Modern OTT platforms encrypt video using CENC (Common Encryption) for Widevine and PlayReady, and CBCS for FairPlay, both built on AES with 128-bit keys as the underlying cipher. 

This is what makes multi-DRM practical: the same encrypted CMAF-packaged segments serve all three DRM systems, because the encryption standard is shared even though each DRM system controls its own license path to the decryption key.

The video file's KID (Key ID) tells the player which key it needs, and the DRM license server, not the CDN, is the only party that ever hands that key over, and only after checking the request against a set of playback rules.

The license and key protection process an auditor expects to see documented runs in this order:

1. Content is encrypted at the packaging stage using CENC or CBCS with a dedicated content key.
2. The content key is stored in a key management system, never embedded in the packaged file or the player application.
3. The player requests a license from the DRM license server when a viewer presses play, sending an authenticated token, not a raw credential.
4. The license server checks authorization against entitlement, device security level, and playback rules before issuing anything.
5. A time-bound license is issued, containing the decryption key wrapped for that specific device and DRM system.
6. The license expires on a defined schedule, and long-lived content keys rotate periodically, particularly for live or high-value content periods.

If your license server issues a license before checking entitlement status, and only logs the failure after the fact, you do not have an authorization system. You have a key vending machine that happens to require an internet connection.

Studios ask specifically whether authorization happens before license issuance, not whether logging catches the mistake afterward.

For teams building this out for the first time, our guide on building multi-DRM setups walks through the packaging and key server side in more technical detail than fits here. 

HLS encryption vs. DRM is worth reading if your current stack relies on basic AES-128 HLS encryption without a full DRM license layer, since studios generally do not accept that as sufficient for premium content regardless of key length.

---

What Are the Content Tier Security Requirements Studios Set?

Studios do not apply one security policy across an entire catalog. Content protection schedules typically scale requirements by resolution and release window, meaning a two-year-old SD catalog title and a day-one 4K release from the same studio can carry entirely different DRM, output protection, and watermarking obligations inside the same app.

Content Tier	Typical DRM Expectation	Hardware Security	Output Protection	Watermarking	Playback Restriction
SD	Widevine L3 acceptable	Not required	Not typically required	Not typically required	Minimal
HD	Widevine L1 preferred	Often required	HDCP 1.4+	Situational	Device limits common
Full HD	Widevine L1 required	Required	HDCP 2.2	Situational to required	Device and concurrency limits
UHD / 4K	Widevine L1 required	Required	HDCP 2.2+	Frequently required, especially early-window	Strict device and geographic limits

Note: Exact rules vary by studio, title, and distribution agreement. This table reflects commonly applied tiers, not a universal mandate.

Worked Example: Catalog SD Title vs. New 4K Release

Say your app carries a five-year-old SD documentary and a day-one 4K theatrical release from the same distributor. The documentary can reasonably run on Widevine L3, no forensic watermarking, and standard HDCP handling, because the content owner's exposure from a leak is low and the title has already had its commercial window.

The 4K release needs Widevine L1 enforced server-side, HDCP 2.2 verified before the stream starts, and forensic watermarking tied to the viewer's session, because a leak in the first 48 hours of an early-window release has a measurably higher cost than the same leak two years later.

Bind the resolution and playback rights to the device's actual security capability on the server side. A client-side check that says "this device supports 4K" is a suggestion an attacker can override.

A server-side check that only issues a 4K-capable license after confirming Widevine L1 and HDCP compliance is a control. This single design decision is what separates platforms that pass tiered content reviews from platforms that get flagged for downgrade risk.

Live sports and live events compress this same tiering logic into a shorter window. A leaked on-demand title can still be pursued through standard takedown channels days later, but a pirated live stream loses most of its commercial value within minutes.

That's why live DRM needs license issuance that holds up under kickoff-time concurrency spikes, forensic watermark extraction measured in minutes rather than hours, and anti-piracy monitoring watching for restreams during the event itself, not after logs are reviewed the next day.

---

Is DRM Alone Enough, or Does it Need to Sit Inside an Authorization Chain?

No, and this is where most platforms leave a real gap. DRM protects license keys and controls playback authorization, but it was never built to stop credential sharing, camcorder piracy, token theft, or every form of screen capture.

A platform can have Widevine L1 and FairPlay both correctly enforced and still leak content, because none of those failure modes involve breaking the DRM itself. They involve someone with legitimate access sharing that access, or someone pointing a second device at the screen.

DRM belongs at the end of an authorization chain, not as the sole gatekeeper. The playback flow that satisfies a studio review runs: user authenticates, entitlement is verified, a playback token is issued, the manifest and license request are authorized against that token, the DRM license is returned, and only then does playback begin.

1. The user authenticates against the platform's identity system.
2. Entitlement is verified, checking subscription status, rental window, or purchase record.
3. A playback token is issued, short-lived and scoped to the specific content and session.
4. The manifest and license request are authorized using that token, not the user's raw credentials.
5. The DRM license is returned, containing the decryption key and its playback rules.
6. Playback begins, with the DRM license enforcing device-level rules the entitlement layer already approved.

Skip step two and DRM alone cannot catch the gap: a canceled subscriber or someone outside the licensed territory can still obtain a working license as long as their device satisfies the DRM's own security rules.

DRM enforces device and playback conditions. It does not, by itself, know whether the person requesting the license is supposed to have access at all. Studios check entitlement as a distinct system for exactly this reason, not as an assumption baked into the DRM layer.

The complementary controls they expect alongside it are signed URLs or tokenized session links to stop link sharing, concurrent stream limits and anomalous login detection to catch credential sharing, and forensic watermarking to trace leaks back to a source once encryption and output protection have both been bypassed by an analog capture method.

What Forensic Watermarking Adds That DRM Cannot

Forensic watermarking embeds a viewer- or session-specific identifier directly into the video frames themselves, invisibly, in a way that survives re-encoding, screen recording, and even filming the screen with a second camera.

Unlike a visible logo watermark, which only deters casual sharing, a forensic watermark is designed to be extracted from a pirated copy after the fact, letting the platform trace the leak back to the specific account or session that produced it.

Studios typically require this for premium, early-window, live, or otherwise high-risk content, precisely because DRM and HDCP cannot stop someone from recording a screen with a phone.

DRM is preventive: it stops unauthorized decryption before playback happens. Watermarking is investigative: it identifies the source after a leak has already occurred. A studio review checks for both because they cover different points in the piracy timeline, and a platform offering only one has a documented hole the other was built to close.

Dynamic vs. forensic watermark breaks down the two approaches in more depth if you're deciding which your content tier needs.

---

Should You Build DRM In-House or Use a Managed Multi-DRM Provider?

Build your own DRM stack when you already employ a content security team and need custom certificate handling that no managed provider offers.

Use a managed multi-DRM provider when audit readiness matters more than owning every layer of the pipeline. Neither approach works when your content volume is too small to justify the DRM add-on cost against your actual piracy risk.

Building in-house means standing up a license server, integrating separately with Widevine and FairPlay certificate programs, building a device support matrix from scratch, and maintaining all of it as each DRM vendor updates its own requirements.

That said, well-built proprietary DRM implementations still struggle to pass on the first attempt, because the certificate handling and device testing burden is large enough that gaps creep in.

Managed DRM providers package the license server, certificate management, and device compatibility testing so a platform doesn't rebuild that infrastructure from parts. Coverage differs between them, and it is worth checking rather than assuming: Gumlet and VdoCipher ship Widevine and FairPlay, while Axinom and other full multi-DRM vendors add PlayReady.

The tradeoff is less granular control over the license server's internals in exchange for a faster path to an audit-ready configuration.

Factor	Build In-House	Managed Multi-DRM Provider
Ownership	Full control over license server and key management	Provider manages license server; platform controls policy settings
Integration burden	High: separate certification with Widevine, FairPlay, PlayReady	Low: single integration covers all three DRM systems
Device coverage	Must build and maintain your own device support matrix	Provider maintains and updates the matrix
Key management	In-house responsibility, including rotation and storage	Handled by provider, typically HSM-backed
Engineering effort	Significant, ongoing as DRM specs update	Minimal after initial setup
Best fit	Platforms with a dedicated content security team and custom certificate needs	Platforms that need audit-ready DRM without building a license server from scratch

Verdict: A platform with an existing security engineering team and specific certificate requirements a managed provider won't accommodate has a real case for building in-house. 

Everyone else moving toward a studio conversation on a normal engineering timeline gets to audit-ready faster with a managed provider, because the device matrix, certificate handling, and license server hardening are already done and already documented.

Gumlet handles Widevine and FairPlay certification, native iOS and Android SDKs, and no-code setup for exactly this reason: the goal is arriving at the audit table with the evidence table above already filled in.

---

What Security Testing Should Happen Before an OTT App Launch or Studio Review?

Pre-launch security testing for OTT DRM should specifically probe license abuse, token replay, entitlement bypass, and rooted-device behavior, the failure modes most likely to surface in a real review and least likely to show up in routine QA.

• License abuse: Attempt to request a license outside the entitlement flow and confirm it fails.
• Token replay: Reuse an expired or already-consumed playback token and confirm the request is rejected.
• Entitlement bypass: Try to access content after a subscription cancellation or outside a permitted territory.
• Manifest leakage: Check whether the video manifest URL is guessable or exposed without authentication.
• Downgraded DRM security: Confirm 4K content is not served to a device reporting Widevine L3.
• Rooted-device behavior: Verify the app's response on a rooted Android device or jailbroken iPhone matches your stated policy.
• HDCP handling: Confirm playback downgrades or blocks correctly when HDCP compliance cannot be verified.
• Offline-license abuse: Test whether an offline license can be extracted, extended, or replayed after expiry.

A platform that has already reproduced and fixed these failure modes internally walks into a studio review saying "tested, here's the result" instead of discovering the gap live in front of the person deciding whether to approve the deal.

---

What Happens When a Viewer's Device Doesn't Support the Required DRM Level?

The policy decision has four possible outcomes, and which one applies should be a server-side rule, not a client-side guess: allow the requested quality anyway, downgrade the resolution to match the device's actual security capability, serve an alternative rendition, or deny playback entirely.

Studio content protection schedules generally specify which of these four is acceptable per content tier, and "allow anyway" is rarely approved for premium or early-window titles.

A device reporting Widevine L3 requesting a 4K stream gated to L1-only is the clearest case: the correct response is a resolution downgrade to whatever tier L3 is permitted to serve, or an outright denial if the title's protection schedule doesn't allow an SD fallback for that release window.

Authorization needs to bind maximum resolution to the device's confirmed security capability at the server, not trust a client-reported flag a modified app or rooted device could falsify.

---

Why Gumlet Fits OTT Apps Preparing for a Studio Security Review

Most of the gaps that fail a studio review, mismatched device security tiers, missing evidence documentation, watermarking bolted on after the fact, come from stitching DRM together from separate vendors under launch pressure.

Gumlet is built as an all-in-one video hosting platform, so DRM, tokenized signed URLs, dynamic watermarking, geo and domain restriction, and encoding sit inside one system instead of three vendor integrations that each need separate audit documentation.

Gumlet ships certified Widevine and FairPlay support with no-code setup and native iOS and Android SDKs, and has blocked over 150 million downloader install attempts across its customer base, a scale of enforcement that reflects production DRM traffic.

Gumlet's video protection features layer signed URLs, password protection, and geo-blocking on top of DRM, covering the entitlement and access-control rows in the audit table that DRM alone doesn't touch. Enterprise plans add SOC 2, ISO, and GDPR-aligned compliance documentation, with DRM included by default.

Current DRM pricing runs as a $99 per month add-on on paid plans, with the first 100,000 protected views included and $1 per 1,000 views thereafter, or bundled into Enterprise alongside SSO and a dedicated Slack escalation channel. Full details are on Gumlet's pricing page.

---

Frequently Asked Questions

1. Does passing a DRM vendor's certification mean a studio will approve my app?

No, vendor certification and studio approval are two different processes. A DRM vendor's certification confirms the technology itself meets that vendor's security standards, but studio approval evaluates your complete implementation: device policies, content tier mapping, evidence documentation, and how the DRM integrates with your entitlement system.

A platform can use fully certified Widevine and FairPlay and still fail a studio review if the surrounding architecture doesn't match what the content protection schedule requires.

2. Can DRM stop someone from filming the screen with a camera?

No, DRM cannot prevent someone from pointing a second device at a screen and recording it, because that capture happens entirely outside the encrypted digital pipeline DRM controls. Forensic watermarking exists specifically to address this gap.

It embeds a viewer-specific identifier into the video that survives being filmed, re-encoded, and redistributed, letting the platform trace a leaked copy back to the account or session that produced it.

3. What is the difference between DRM, encryption, and signed URLs?

Encryption makes a video file unreadable without a key. DRM controls who receives that key, under what conditions, and for how long. Signed URLs restrict access to a video file by expiring the link after a set time or limiting it to a specific session, which stops casual link sharing but does nothing to protect the video content itself once accessed.

A studio-grade setup uses all three together: encryption on the file, DRM controlling key access, and signed URLs preventing the encrypted stream's location from being freely shared.

4. What is SPEKE and do I need it for multi-DRM?

SPEKE (Secure Packager and Encoder Key Exchange) is a standardized protocol that lets your video packager request encryption keys from a key management service without custom integration work for each DRM system.

Running multi-DRM against more than one key provider is exactly when SPEKE matters: it keeps packaging and key exchange interoperable instead of requiring separate code per DRM vendor. Most managed key management services support it by default.

5. How often should DRM and content protection controls be re-audited?

Trigger a review any time you change your player, DRM vendor, device platform support, or infrastructure, in addition to a recurring review on a fixed interval.

MovieLabs has updated its Enhanced Content Protection specification several times since it first published in 2013, most recently reaching version 1.4 in August 2024, so a cadence tied only to a calendar date will eventually miss a requirement that changed between reviews.

Platforms that treat re-audits as event-driven rather than purely calendar-driven catch more of these gaps before a studio does.

---

The Takeaway

DRM is necessary and it is not sufficient. The platforms that pass studio security reviews on the first attempt are the ones that treat DRM as one row in a larger audit table, matched to content tier, backed by documented evidence, and layered with entitlement checks, output protection, and watermarking that each cover a gap DRM was never designed to close.

If you're preparing for a studio or distributor conversation, the fastest path is auditing your current stack against the evidence table above before someone else does it for you.

Schedule a demo with Gumlet to walk through your specific content tiers, device matrix, and what's already audit-ready versus what still needs documentation.