SLAs, support policy, hosting and delivery, and the data processing agreement: the documents that move without your signature. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session four of thirty, and the last stop in the written stack before we get to money. Quick recap of where we stand: session two gave you the master and the precedence rule, session three gave you the orders where the power lives. Today, the layer underneath both: the policies. The SLAs, the support policy, hosting and delivery, and the data processing agreement. Here's why this session earns its slot: these are the documents that govern your worst days. The outage, the Sev 1, the breach notification, the regulator's questionnaire. And they share a property that should keep you slightly alert: most of them can be revised by Oracle, mid term, without your signature. We'll spend real time on the one exception, the DPA, and we'll end with a discipline that costs an hour a quarter and removes almost all of the risk. Let's go.
Five takeaways today. One, the map: which policy documents ride under every Oracle cloud order, what each one governs, and, importantly, which ones your regulators will ask about by name. Two, the SLA, properly this time: session two gave you the headline, credits as sole remedy, today you get the three service level families, the scale, and the claim mechanics end to end. Three, the support reality: what your subscription actually includes when production is down at two in the morning, and where support quietly ends and paid services begin. Four, the data terms: the DPA, subprocessors, residency, breach clocks, the material your compliance function needs before any regulated workload goes live. And five, the watch discipline: a quarterly routine, one hour, one owner, that catches policy drift before it becomes an audit finding or an outage surprise.
The map first. Four document families, all incorporated by reference into your stack, all published by Oracle, most revisable mid term. Family one, the service level agreements: availability targets per service, the credit scale for misses, and the claim process. This is the only remedy the entire stack gives you for downtime, so we'll dissect it properly in a minute. Family two, the cloud support policy: what support your subscription includes, severity definitions, response targets, escalation. The humans, as opposed to the credits. Family three, hosting and delivery: where and how the service physically runs, regions, security practices, business continuity, maintenance, and the operational mechanics of suspension. And family four, the data processing agreement, the DPA: the privacy machinery, processor obligations, subprocessor lists, cross border transfers, breach notice, and your audit rights over Oracle itself. Hold session two's frame as you look at these: the load bearing promise underneath all four is that Oracle won't materially reduce the service you've paid for, during the term you've paid for. Everything softer than that can move. Now let's open the one you'll use most.
The SLA, in full. Three families of service level. Availability: monthly uptime percentage per service, measured by Oracle, paying service credits on a sliding scale against that service's monthly fee when it's missed. Management: whether the control plane responds, provisioning, scaling, the console. A service can be up while its management plane is down, and that's separately claimable. And performance: whether the service performs within its published parameters, the hardest family to evidence, because degraded is a fight in a way that down never is. Three things are true across all families. First, Oracle measures. The contractual telemetry is theirs, which has consequences we'll hit in the knowledge check. Second, nothing pays automatically. A claim, inside the window, with evidence, or no credit, ever. And third, the ceiling: credits cap at a fraction of the monthly fee for the affected service, never consequential damages, and the SLA is drafted as your sole remedy, which you knew from session two. So let me repeat the strategic frame, because it's the whole game: the credits are small by design. The documented pattern of misses is not small. File every claim on principle, log every incident, and spend the folder where it pays, at the renewal, as price and terms.
First check. Fusion was degraded for six hours. Oracle's status page showed green the whole time. Your own monitoring recorded the outage minute by minute. What decides whether you see a credit? A, Oracle's status page, if it showed green, no miss occurred contractually. B, a claim filed inside the window carrying your own monitoring evidence, because Oracle measures, but a documented claim forces the reconciliation. C, nothing, performance degradation never qualifies. Or D, the account manager's goodwill at the next business review. Pause here. Whose measurement, whose claim, whose deadline?
The answer is B, and the reasoning matters more than the letter. Yes, the SLA runs on Oracle's measurement. But a status page is a public summary, not a contractual verdict, and when you file a timely claim with independent evidence, Oracle has to reconcile its telemetry against yours. In practice, well evidenced claims routinely pay, and poorly evidenced complaints routinely don't. That's the whole difference. A is the trap of learned helplessness: green dashboard, shrug, move on, and six hours of degradation vanish from history. C is wrong because the performance family exists precisely for degradation, it's just evidence hungry, which is why your own monitoring is a licensing control, not just an ops tool. And D, goodwill, is real but it's what you use after the contractual route, to top it up, never instead of it, because goodwill doesn't compound and folders do. One more time, the discipline: monitor independently, claim every miss inside the window, keep everything. Your homework this week includes finding out exactly how many days that window gives you. Most teams are surprised how short it is.
Now the humans: the cloud support policy, and what your subscription actually buys you at two in the morning. Severity levels first. Sev 1, production down, complete loss of service, gets round the clock effort and the only genuinely hard response targets in the document. Everything below Sev 1 runs business hours and reasonable effort. Two practical rules fall out of that: classify honestly, because crying Sev 1 for cosmetic issues burns credibility you'll want later, but classify firmly, because the level you file at starts the clock, and downgrading a real Sev 1 to be polite is a gift nobody remembers. Second, and read this one twice: response is not resolution. The targets promise a qualified human engaging with your ticket, not a fix, and nothing anywhere in the policy commits to time to resolve. Which is why your documented Sev 1 history, how many, how long, business impact, is renewal material of the first order. Third, the scope boundary: support covers the service not working as documented. How do I questions, configuration help, performance tuning, all of that drifts toward paid services, and the line is worth knowing before an incident blurs it. Fourth, escalation: the formal escalation manager route exists and genuinely works, and the account team route runs in parallel, and for a real Sev 1 you use both, in writing. And fifth, keep the documents straight: the SLA pays credits for downtime, the support policy governs the help. A heroic support engineer doesn't waive your missed SLA, and a paid credit doesn't fix your ticket.
Hosting and delivery, the operational fine print, five items. One, regions and residency: the policy names where services can run, your order names your region, and moving between regions later is a project with contract implications, not a console toggle. Decide the region like it's permanent, because commercially it nearly is. Two, maintenance: Oracle schedules maintenance with notice, and on the SaaS side, the quarterly updates are mandatory. Not mandatory ish. Mandatory. We'll do a whole knowledge check on that because change boards keep re-losing this fight. Three, business continuity: the policy describes Oracle's own disaster recovery posture per service tier, and your resilience review should quote what the paper actually says rather than what everyone assumes it says. The gap between those two is a finding waiting to happen. Four, suspension mechanics: session two gave you the right, this policy gives you the how, notice, cure, scope, the operational sequence. And five, change management: the policy explicitly reserves Oracle's right to update infrastructure, security measures, and operational practice, with the no material reduction promise as the only fence. Which sets up the data conversation perfectly, because if the operational layer moves, what happens to the layer your regulators care about?
Check two. Your change board wants to defer Oracle's quarterly Fusion update by two months, to fit inside an established freeze window. The accurate position is: A, updates can be declined indefinitely with written notice. B, quarterly SaaS updates are mandatory on Oracle's calendar, you control limited scheduling within the window and your own test cycle, but not whether the update lands. C, a deferral fee of ten percent buys you a quarter's delay. Or D, apply it to production only and skip test. Pause here. Whose release calendar governs a SaaS estate?
The answer is B. One code line for every customer is the economic foundation of SaaS, it's why the price is what it is, and it means the quarterly update lands, for everyone, on Oracle's rhythm. You get limited scheduling flexibility inside the window, you get test environments updated ahead of production by design, and that's the extent of your control over the calendar. There's no indefinite deferral, no deferral fee, and D, skipping test, is how a mandatory update becomes a production incident with your name on it. Now, the deeper point, because this check is really about posture: estates that keep fighting the update calendar lose quarterly, forever. Estates that accept it flip the control point from refusal to readiness, they invest in regression automation, they align their freeze windows to Oracle's published schedule instead of against it, and the quarterly update becomes a non event. Your change board's power here isn't veto. It's preparation. Redirect the energy accordingly, and put the release calendar in the same shared calendar that session two's notice windows went into.
Now the exception in the policy layer, the document with actual teeth: the data processing agreement. It binds harder than the rest for a simple reason, privacy law stands behind it, and your regulator reads it. Four corners. Roles and instructions: you're the controller, Oracle is the processor, and the DPA plus your order constitute the processing instructions. That framing matters, everything Oracle does with your data traces back to an instruction or a legal basis, and that's a compliance answer you'll give repeatedly. Subprocessors: Oracle discloses the list and commits to notifying changes. Your compliance function should be subscribed to those notices, personally, not via a shared inbox that nobody owns, and yes, objection rights exist, and no, they're not broad in practice, but the notice is where your assessment obligations start. Transfers and breach: the cross border transfer mechanisms live inside the DPA, and the breach notification commitment runs to you on a defined clock. Your incident response plan should quote that clock verbatim rather than guess it, because during a real incident nobody has time to go find the paper. And audit rights: the DPA gives you, the controller, audit rights over Oracle, satisfied in the normal case by certifications and reports, SOC 2, ISO, with direct audit as the escalation path. Here's the free win in this whole session: those reports are included in what you're already paying for, and almost nobody collects them. Ask annually. It costs an email.
Data residency and sovereignty, five questions to answer on paper before any regulated workload signs. One, where does the data rest? Your order names the region, and the service description may name a secondary region for disaster recovery, and a regulator cares about both, not just the first. Two, where is it processed? Because support access and operations can cross borders even when storage doesn't, and answering this takes the DPA and the hosting policy together, neither document alone covers it. Three, who can access it? Oracle operations staff under defined access models, break glass procedures for emergencies, and, if you need to narrow that, customer controlled encryption key options exist as priced tiers of control. Four, what survives termination? Session two's retrieval window plus the DPA's deletion commitments, and here's the subtle one, your own records retention obligations may legally outlive Oracle's deletion clock, so reconcile those two timelines in writing before they conflict in reality. And five, which construct fits? Public region, the EU sovereign options, a dedicated region, or Cloud at Customer on your own datacenter floor. Sovereignty is bought in tiers, each tier costs more, and module three prices them properly. Before we do the last check, let's hear from our advisor on how this plays out in a genuinely regulated estate.
Guest analyst I took a European bank through an Oracle cloud negotiation last year, and the policy layer was half the deal. Here is what regulated buyers do differently. They do not accept the policy layer as read; they extract the parts they cannot live without and pin them into the order as special terms. Named certifications that must be maintained for the term. The region, named, with a consent requirement for any change. Customer managed keys, named. A breach notice clock tighter than the default, named. Oracle signs these, routinely, for regulated customers who ask at signature, because the deal desk has approved language for every one of them sitting in a drawer. The second thing they do is treat the DPA as a living obligation, not a signing formality. One person owns the subprocessor notices. The SOC reports are collected every year and actually read, and twice now a finding in that reading has changed an architecture decision. And the third thing: they wrote the exit into the resilience plan. Not because they expected to leave, but because their regulator literally asks for a documented exit strategy from every material outsourcer, and a retrieval window you have never tested is not a strategy, it is a sentence in a contract. None of this made the deal slower, by the way. It made it boring. Regulated deals should be boring.
Pin what you can't live without, own the notices, test the exit. And notice his framing: the deal desk has approved language sitting in a drawer for all of it. You're rarely asking Oracle to invent something, you're asking them to attach what already exists, which is why regulated buyers who ask at signature get it, and buyers who ask mid term get sympathy.
Last check. Compliance asks you directly: can Oracle change the security measures described in the hosting and delivery policy mid term, and if they do, what protects us? A, no, every policy is frozen for the term at signature. B, yes, policies can be updated, and the protections are the no material reduction promise, the DPA's binding commitments, and anything you pinned into the order as a special term. C, yes, and nothing protects you, cloud is take it or leave it. Or D, only with twelve months notice and your written consent. Pause here. Session two's three buckets: what moves, what's promised, what you pinned.
The answer is B, and it's the whole session in one answer. Yes, the hosting and delivery terms are Oracle's documents and they move, that's the design of the layer, and pretending otherwise, answer A, sets compliance up for a nasty surprise. But C's fatalism is equally wrong, because three fences genuinely hold. Fence one, the CSA's promise: no material reduction of the service you've paid for during your term. Narrower than it sounds, but real. Fence two, the DPA: its commitments are enforceable in a way ordinary policies aren't, because privacy law backs them. And fence three, the one you control: whatever you pinned into the order. Named certifications, named region, named key controls, the regulated buyer's list from the clip. So the answer to compliance is a sentence you can now say precisely: the operational layer can move, our must haves are pinned in the order, the DPA binds, and we monitor the rest quarterly. Which brings us to how, exactly, you monitor the rest quarterly.
The policy watch discipline, one hour a quarter, one named owner. Step one, snapshot the set: save dated copies of the four documents as they stood at your signature, the SLA, support policy, hosting and delivery, and DPA. Every future change conversation starts from what you signed against, and without the snapshot you're arguing from memory against a vendor with version control. Step two, diff quarterly: the owner re pulls the four current documents, diffs against the snapshot, and anything material goes on the risk log the same day. Most quarters this takes twenty minutes and finds nothing, which is the point. Step three, subscribe to the subprocessor notices, routed to compliance by name. Step four, collect the certifications annually through the DPA route, SOC and ISO, filed with the snapshots, so your audit over Oracle is a folder you maintain rather than a scramble you survive. And step five, feed the renewal file: SLA claims, Sev 1 history, policy drift, all of it lands in the same folder as session two's evidence, because the renewal is where the policy layer converts into terms. There's a theme across this whole module, and this is the last time I'll say it before we get to money: none of these disciplines is clever. They're just owned, dated, and repeated. That's what separates estates that get surprised from estates that don't.
Session four, three sentences. One: four policy families ride under every order, SLAs, support, hosting and delivery, and the DPA, and all but the DPA move at Oracle's hand, fenced only by the no material reduction promise and whatever you pinned into the order. Two: the SLA pays credits only to claimants with evidence, support promises response and never resolution, and the quarterly SaaS update lands whether your freeze calendar likes it or not, so the control point is readiness, not refusal. Three: the DPA is the policy with teeth, subprocessor notices, transfer mechanisms, breach clocks, and audit rights over Oracle that regulated estates should exercise annually, on calm days, instead of discovering under pressure. That closes the written stack: master, orders, policies. You can now read an entire Oracle cloud contract structure top to bottom, which puts you ahead of most people who sign them. Next session, the module finale, we finally talk about money: cloud pricing mechanics, list versus net, what discounts actually land by deal size for credits and for SaaS, and the negotiation calendar that moves all of it. Bring your net rate from session three's homework. We're going to find out if it's any good.
Homework, about an hour, and it builds the folder this session kept talking about. One, pull the four documents: the SLA, support policy, hosting and delivery, and DPA versions that apply to your largest cloud service, date stamp them, and file them. That's your snapshot, and it took ten minutes. Two, find your claim window: the exact number of days the SLA gives you to claim a credit. Write it somewhere the operations team will actually see it, because a claim window nobody knows about is a remedy nobody has. Three, check your monitoring honestly: if Fusion or your OCI workload degraded for six hours tomorrow, could you evidence it independently? If the answer is no, you've found this quarter's fix, and it's cheaper than one missed claim. Four, route the notices: find out who currently receives subprocessor change notifications. If the answer is nobody, fix it today, it's a form. And five, ask for the reports: request the current SOC and ISO reports through your DPA rights. They're included in what you already pay. Collecting them costs one email, and the day a regulator asks, you'll look like the most organized customer they've seen all year.
Five reads before next session, all free on redress compliance dot com. First, Oracle support policy incorporation by reference, the legal mechanism this whole session rides on, how documents you never signed become part of your deal. Second, the Oracle cloud licensing policy guide for twenty twenty six, the current policy layer mapped end to end, the written companion to your new watch discipline. Third, Oracle cloud contracts and credits for CIOs, one level up, where the policy layer sits in the executive view. Fourth, Cloud at Customer versus OCI, the sovereignty tiers priced, for when the public region stops being enough. And fifth, the dedicated region guide, the top of that ladder, and the commitments it takes to get one. That's session four, and that's the entire written stack behind you: the master, the orders, and the policies. Next time, money. List, net, and what good actually looks like. See you there.