Introduction
Many CIOs consider third-party support services as an alternative to Oracle’s official support for databases and enterprise applications. Third-party support (provided by independent vendors rather than Oracle) can significantly reduce costs and extend the life of stable Oracle systems. However, moving away from Oracle’s umbrella raises critical questions about security and compliance. CIOs must ensure that their systems remain protected even without Oracle’s regular patches and oversight and that they meet all regulatory and contractual requirements. This article, written from the perspective of an Oracle licensing expert, provides an executive-level overview of the key security responsibilities and compliance considerations when evaluating Oracle third-party support. It offers a neutral look at how leading third-party providers address these issues, common misconceptions about losing visibility or control, and the trade-offs between staying with Oracle versus switching to an independent support vendor, all in the context of risk management and best practices.
Oracle Third-Party Support Overview
What is Third-Party Support? In the Oracle context, third-party support refers to maintenance and support services delivered by an independent provider (not Oracle) for Oracle software that you have licensed. Instead of paying Oracle’s annual support fees, an organization contracts a firm like Rimini Street or Spinnaker Support (two leading providers) to handle break-fix support, patches, and updates for Oracle products. This allows companies to avoid Oracle’s high support costs and to continue running older Oracle versions beyond Oracle’s official end-of-support dates. In essence, third-party support lets the customer dictate their IT roadmap – deciding if and when to upgrade – rather than being forced into Oracle’s upgrade cycle just to remain supported.
Why Consider It? The primary driver is typically cost savings: Oracle’s standard support fees are about 22% of the license price annually, and many CIOs report that switching to a third-party provider can cut support costs by 50% or more. Additionally, third-party vendors will support heavily customized and legacy Oracle systems with personalized service, whereas Oracle’s support might decline assistance on custom code or push for expensive upgrades. The flexibility and customer-centric service are attractive, but they come with a responsibility: the CIO must be confident that security and compliance will be rigorously managed outside Oracle’s direct purview.
Security Responsibilities in Third-Party Support
When considering third-party support, security remains a top responsibility for the CIO. You will no longer receive Oracle’s periodic security patch bundles, so assessing how security will be maintained through alternative means is critical. Key security domains to evaluate include:
- Vulnerability Management & Patching: Without Oracle’s patches, the third-party provider needs a robust process for identifying and fixing vulnerabilities in Oracle software. Leading providers use techniques like “virtual patching” – analyzing newly discovered vulnerabilities and creating remedial measures without accessing Oracle’s source code. For example, if a security flaw is identified, the provider might develop a custom script or configuration change that closes the security gap or apply a firewall rule to block an exploit signature. They often deliver these fixes more rapidly than Oracle’s quarterly patch cycle, ensuring you don’t have to wait months for critical updates. A strong third-party support partner will also monitor sources of threat intelligence (such as CVE disclosures) and proactively alert and protect you when new vulnerabilities emerge. CIOs must verify that the vendor has a proven methodology to address vulnerabilities promptly and thoroughly.
- Data Security and Access Controls: Shifting support to a third party does not diminish the importance of protecting sensitive data. The CIO should ensure that any support provider adheres to strict data protection standards – for example, compliance with GDPR privacy rules or HIPAA security requirements if applicable. Top third-party providers commit to following major regulations (GDPR, HIPAA, SOX, etc.) and implement comprehensive security measures like encryption of data, strong user access controls, and regular security audits. It’s wise to confirm that the provider’s personnel access your systems securely, controlled (e.g., VPNs, multifactor authentication, and read-only access where appropriate), and that they won’t expose or mishandle company data. Fundamentally, the third party’s involvement should not introduce new insider threats or data leakage risks, so their internal security practices and certifications (such as ISO 27001 for information security management) should be scrutinized.
- Monitoring and Incident Response: Under Oracle support, you may have relied on Oracle’s alerts for critical issues; with independent support, you should establish how ongoing monitoring and incident response will work. Many third-party support vendors provide 24/7 security monitoring and will send advisories for emerging threats. CIOs should ask if the provider has an established Security Operations Center (SOC) or similar capability to promptly detect suspicious activity or signs of attack on the Oracle systems. It’s also important to integrate your own security team’s efforts with the provider’s – for instance, ensure your SIEM (Security Information and Event Management) tools still get the necessary logs and that there is a clear process to escalate and resolve security incidents. The goal is that even without Oracle’s direct involvement, you maintain full visibility into your systems’ security status and can respond quickly to any incident.
In practice, many organizations have found that working with a third-party support partner can improve certain aspects of security. Rather than solely relying on reactive patches, third-party providers often take a defense-in-depth approach – reducing the overall attack surface and hardening the environment proactively. They may assist with secure configurations and operational best practices in addition to providing fixes. Still, the effectiveness of this approach hinges on the provider’s expertise. As a CIO, you must vet the security credentials and track record of the third-party vendor. Look for providers with experienced Oracle engineers (often ex-Oracle staff) and those who can cite real-world success in preventing breaches. Notably, to date there have been no major public security incidents attributed to companies using third-party support – even large banks and government agencies have operated on third-party support for years without Oracle’s patches and without incident. This track record suggests the model can be safe, provided that rigorous security processes are in place and continuously maintained. The responsibility is on both the CIO and the support vendor to stay vigilant.
Compliance and Oracle Licensing Considerations
Beyond technical security, CIOs must address compliance concerns when leaving Oracle’s official support. These concerns span external regulations, internal policies, and Oracle’s own licensing rules:
- Regulatory and Industry Compliance: Organizations in regulated industries worry about staying compliant with standards like GDPR (data protection for EU residents), HIPAA (healthcare data security), SOX (financial reporting controls), PCI-DSS (payment card security), and others. There is a misconception that using third-party support might violate regulations or be frowned upon by auditors. In reality, regulations typically do not mandate that you obtain support from the original software vendor, but they require that you protect data and promptly address known vulnerabilities. CIOs should ensure that their third-party support plan includes a method to apply necessary regulatory updates and security fixes instead of Oracle patches. For example, suppose Oracle releases a patch to address a critical vulnerability that could impact data privacy. In that case, you need evidence that your third-party provider either provided an equivalent fix or mitigation or that you implemented other controls to manage the risk. Documenting this process is crucial: Auditors will ask how you keep systems secure and up-to-date without Oracle’s updates. Leading third-party providers can help in this area – they often support legacy software versions that Oracle no longer maintains, thereby increasing your compliance coverage (since running unsupported software can be a compliance risk). They also deliver updates for legal/tax changes (for example, changes in payroll tax law for an Oracle E-Business Suite HR module) so that you remain compliant with government requirements. The key is to treat the third-party support arrangement as part of your compliance program: conduct regular security assessments, retain documentation of all fixes applied, and ensure the provider’s work aligns with your regulatory obligations. With proper oversight, finance, healthcare, and public sector companies have successfully passed audits while on third-party support, demonstrating strong compensating controls and vendor support processes.
- Oracle Contractual Constraints and Audit Risk: From a licensing standpoint, Oracle’s support contracts include certain rules that CIOs must navigate carefully when switching to a third-party. First, know that using a third-party support provider is legal and permitted as long as you comply with your Oracle license agreement. Courts have affirmed that Oracle customers can hire a third party to support licensed software. Oracle cannot terminate your licenses simply because you choose not to renew support. However, you must stay within the bounds of your license: this means you cannot apply Oracle’s patches or updates beyond the ones you already have rights to, and you cannot run more licenses or features than you’ve paid for. It’s wise to perform an internal license audit (or work with an Oracle licensing expert) before leaving Oracle support. Verify that all your deployments are properly licensed, review your contracts for non-standard clauses, and resolve compliance gaps. One common contractual nuance is Oracle’s “Matching Service Levels” policy or license set rules. For instance, Oracle may require that if you drop support on one database license, all other licenses of that same product owned by your company must also be unsupported (you can’t partially support some and not others in the same license set). These rules mean a “halfway” approach needs careful planning to avoid inadvertently breaching your agreement. Work with legal counsel to interpret your contracts and potentially negotiate carve-outs with Oracle if you plan a partial transition.
Once you leave Oracle support, be prepared for the possibility of an Oracle license audit. Some industry observers note that the audit risk can increase after moving to third-party support. Oracle knows you are no longer a paying support customer and may initiate an audit to ensure you’re not using unauthorized software or updates. To mitigate this, keep diligent records: archive any Oracle-provided patches and documentation you received while you were under Oracle support (since you’ll lose access to Oracle’s support portal going forward). Maintain proof of what patches were applied up to the point of leaving Oracle, and document all changes made under third-party support thereafter. This creates an evidence trail to show auditors that you have not illicitly obtained Oracle’s intellectual property after terminating support. It’s also important that your third-party provider operates within legal boundaries – reputable providers develop their fixes or give instructions to customers for fixes. Still, they will not distribute Oracle’s proprietary code (which would violate copyright). For example, the U.S. courts have explicitly held that nothing in Oracle’s license agreements prohibits customers from hiring a third party to create updates or fixes within the scope of the customer’s license rights. In other words, your provider can write new code or workaround scripts that you, as the licensee, can apply. As long as neither you nor the provider uses Oracle’s software beyond what you’re entitled to, you can stay on the right side of compliance. CIOs should have frank discussions with potential providers about how they develop patches and ensure no Oracle IP is misused.
In summary, due diligence in licensing is essential before and after the switch. Companies that plan properly – checking contracts, staying compliant, and documenting everything – have successfully navigated audits even after years on third-party support. Those who neglect this could face disputes or fees, so it’s an area no CIO should overlook.
How Third-Party Vendors Mitigate Security & Compliance Risks
Third-party support vendors know that security and compliance are their clients’ foremost concerns. Over the years, leading providers have built out capabilities to address these concerns head-on:
- Proactive Security Measures: Top providers invest heavily in security research and services to compensate for the lack of official Oracle patches. They typically maintain a dedicated security team that monitors emerging threats to Oracle software. For example, suppose Oracle announces a vulnerability in its quarterly Critical Patch Update. In that case, a third-party support firm will analyze that vulnerability and determine how to protect customers who cannot apply Oracle’s patch. Solutions might include custom code fixes, suggesting configuration changes, or deploying virtual patches at the network level (like web application firewall rules). Some providers offer proprietary security tools; one well-known vendor offers an advanced database security solution that intercepts and neutralizes attacks at the database layer without requiring core code changes. The advantage of these approaches is that they can often be implemented faster and with less downtime than Oracle’s official patches. Additionally, third-party support agreements usually come with personalized support from senior engineers, which means if you have a security issue, you’re more likely to get an expert on the line immediately rather than a tiered support queue. This can facilitate quicker resolution of security incidents.
- Certifications and Standards: As proof of their security posture, reputable third-party support providers often hold industry certifications and undergo independent audits. Look for providers that are ISO 27001 certified (indicating they follow strict information security management practices) or SOC 2 audited for security and confidentiality. These certifications demonstrate that the provider has formalized security policies, access controls, data encryption practices, and breach response procedures – all of which help protect your systems. Providers should also comply with data protection regulations in their operations. For instance, a third-party support partner should be able to affirm GDPR compliance (for any personal data processing they do) and sign business associate agreements if you are a HIPAA-regulated entity. In short, they must meet the same security and privacy bar you hold internally. Never hesitate to ask for a provider’s security documentation, policies, and incident history during your evaluation. A trustworthy vendor will be transparent about their security program.
- Regulatory and Tax Updates: A challenge in enterprise applications is keeping up with regulatory changes (like new tax laws, payroll regulations, or financial reporting rules). Oracle delivers these updates to supported customers (especially for ERP systems), but third-party providers have developed their update services to ensure customers remain compliant. For example, run an Oracle E-Business Suite financial module. As laws change, an independent support vendor typically provides patches or scripts to update tax rates, payroll tables, or other compliance-related data. They often have experts tracking legislation in various countries and proactively creating updates for their clients. This service ensures that moving to third-party support does not mean falling out of compliance with government or industry mandates. As noted earlier, if you’re on an older software release that Oracle stopped updating, the third party’s willingness to create new regulatory updates for it can be the only way to stay compliant, short of a full upgrade. Leading providers highlight this as a value-add: you won’t be stranded if a new law or requirement arises.
- Audit and License Support: The best third-party support vendors also assist customers in navigating Oracle license compliance. They know Oracle’s auditing practices and can help prepare documentation or guide you on what to say and not say during an audit. Some even offer specific license management services, performing license assessments to ensure you remain in compliance. While the responsibility ultimately lies with the customer, having a vendor who understands Oracle’s contracts can be a big help. They can warn you, for example, if a certain reconfiguration of your Oracle environment might accidentally trigger a licensing issue. This advisory role is something to consider as part of the support offering – it can provide peace of mind that you’re not going it alone in the face of Oracle’s license rules.
CIOs should include these security and compliance offerings in evaluating third-party providers as part of the selection criteria. One provider might have stronger security tooling, while another might excel in regulatory updates for a particular industry, so align their strengths with your company’s needs. Reputable third-party support firms understand that trust is paramount in this business. They know clients will only switch from Oracle if they feel confident that security will be handled and compliance will be upheld. Accordingly, top providers strive to demonstrate that they can maintain a secure, compliant environment on par with (or even better than) Oracle’s standard support. Numerous Fortune 500 enterprises and public agencies have made this switch successfully, indicating that the marketplace now has viable options, but due diligence is key in picking the right partner.
Misconceptions About Losing Visibility or Control
Considering a move away from Oracle’s direct support often provokes anxiety within IT leadership. Several misconceptions persist among CIOs and their teams about what third-party support means for control and visibility over their Oracle environment:
- “We will lose visibility into vulnerabilities and patches.” It’s natural to fear that without Oracle feeding you patches and alerts, you won’t know when something needs fixing. In reality, third-party support does not leave you in the dark. You still receive vulnerability information via a different channel. Independent providers supply their security bulletins and guidance, often tracking the same CVEs and threats that Oracle addresses. You may get more personalized notifications because you are a direct customer of the provider (not one of thousands of Oracle support customers).
Nothing stops your security team from following Oracle’s public critical patch updates and working with the third party on equivalent mitigations. You maintain full visibility by staying engaged: require regular security review meetings with the provider, and leverage your existing monitoring tools. You are still running the systems in your environment, so all your usual logs and performance data remain available. In short, you remain in control of monitoring your Oracle systems’ health – the support partner is there to assist and advise, but not to take over your IT operations entirely. - “Our IT team will lose control over the system’s fate.” Some CIOs worry that relying on a third party means ceding control or being at the mercy of an external company. The truth is almost the opposite: companies often regain control over their Oracle roadmap when leaving Oracle support. Under Oracle, if a version goes out of support, you must upgrade on Oracle’s schedule or negotiate expensive extended support – Oracle dictates the timeline. With third-party support, you decide when or if an upgrade happens based on business needs, since the third-party will continue to support your current version indefinitely. This freedom can be empowering; Oracle’s dictated end-of-life dates no longer constrain you. Of course, you do rely on the third-party vendor for fixes, but service agreements can be crafted to ensure you have the responsiveness and resolution commitments you require. You should establish clear SLAs with the provider to know exactly what to expect. This contractual clarity increases control because you can hold the provider accountable to specific metrics (response times, etc.). Internally, your team controls configuration management, user access, and when fixes should be applied. Nothing changes in your change management process except the source of patches. Thus, it’s a misconception that you “lose control” – if anything, you gain more strategic control (over upgrade timing and spending) while maintaining operational control over your systems.
- “We risk falling out of compliance or getting in trouble with Oracle.” Fear of the unknown can make third-party support seem riskier than it is. Oracle sales representatives often warn customers that leaving official support is dangerous or even imply it’s not allowed. These claims are largely FUD (fear, uncertainty, doubt). As discussed, third-party support is legally allowed, and customers retain their license rights. You won’t be penalized just for switching support providers. You can avoid compliance issues by planning carefully (auditing your licenses, not using Oracle’s support portal after leaving, etc.). Leading support vendors will guide you on these dos and don’ts as part of their service. There is also a misconception that you won’t be able to get back on Oracle support if needed. While Oracle imposes financial penalties to reinstate support (back support fees or new license purchases), it’s not impossible – it just requires budgeting for that scenario. Some CIOs keep a small subset of critical systems on Oracle support as a fallback or purchase Oracle’s services only when they plan a major upgrade, using third-party support the rest of the time. This hybrid approach can alleviate the fear of being “stuck.” Ultimately, CIOs do not lose control of their destiny by choosing third-party support; they simply take on different management tasks. The common fears around security visibility and compliance can be dispelled with knowledge and preparation.
Trade-Offs: Oracle Support vs. Third-Party Support
Regarding risk management and long-term strategy, CIOs must weigh the trade-offs between staying with Oracle’s official support and moving to third-party support. Both options have distinct advantages and downsides:
- Oracle Official Support – Pros: By remaining with Oracle, you guarantee access to all official patches, security updates, and new version releases as they become available. This can simplify compliance since applying Oracle-supplied updates is often seen as the straightforward way to fix vulnerabilities. You also maintain a direct channel to Oracle’s development teams for critical product bugs; if there’s a serious issue in the software, Oracle is ultimately the only party to issue a permanent source-code fix or provide an upgrade path. For organizations that need to stay on the cutting edge of Oracle’s technology (e.g., adopting the latest features, or preparing to move to Oracle Cloud offerings), staying on Oracle support is usually necessary. Additionally, you avoid contention with Oracle over contracts – a support switch triggers no additional audit scrutiny. In high-change environments, where new patches and features are needed frequently, Oracle support aligns with those needs.
- Oracle Official Support – Cons: The well-known drawback is cost. Oracle’s support fees are substantial (roughly 20–22% of license cost per year) and tend to increase over time. Many CIOs feel they pay a premium and get mediocre service in return – support tickets might take a long time to resolve and often involve junior support staff following scripts. Another con is the lack of flexibility: Oracle’s policies will force you to upgrade software versions once support for your version expires, or pay extra for extended support if available. This can disrupt stable systems and consume significant resources to remain compliant with support. Oracle also generally does not support customizations – if your Oracle application is heavily customized, Oracle might require you to reproduce issues in an uncustomized environment (which is impractical), effectively leaving gaps in support for your tailored solutions. These factors mean that organizations with tight IT budgets, or those running very stable, customized systems, see Oracle’s support model as high-cost and somewhat inflexible for their needs.
- Third-Party Support – Pros: Third-party support shines in cost savings and flexibility. Companies often save 50% or more on annual support costs, freeing budget for innovation or other priorities. You can run older Oracle versions indefinitely with support, eliminating forced upgrades; the business dictates the timeline for any changes, not the vendor. Support quality can also improve: third-party providers typically offer more personalized and faster support, with experienced engineers who troubleshoot issues in your environment. They will support your customizations and tailor fixes to your specific setup, which Oracle’s support would not do. Another advantage is the comprehensive approach to system maintenance – beyond break-fix, third-party vendors often assist with performance tuning, interoperability issues, and even advisory services to extend the system’s life. From a risk perspective, third-party support can reduce operational risk of change by avoiding constantly applying Oracle’s updates (each of which could introduce new bugs or require testing). Instead, you apply fixes only as needed. Companies that primarily need stability and cost reduction benefit greatly from this model.
- Third-Party Support – Cons: The trade-off is that you forgo Oracle’s continuous stream of official patches and updates. Security risk must be managed in new ways, as detailed earlier. You are entrusting another firm to deliver timely fixes or mitigations for any new threats, which requires trust and verification. Suppose a severe zero-day vulnerability hits your Oracle system. In that case, you will rely on the third-party provider’s ability to respond (or you’ll need to engineer a workaround internally), since Oracle won’t assist you unless you re-enter their support (which could be costly and slow). Another con is that you won’t receive new product features or enhancements; third-party support typically covers the software in its current state (they will fix issues, but not provide new functionality). Over a long period, this could put you behind in technology, unless you plan to eventually upgrade by re-engaging Oracle or transitioning to a different platform. There’s also a re-entry cost to consider: if you decide to go back to Oracle support (say to upgrade to a new version), Oracle may charge back-support fees or require you to purchase new licenses. This can offset some of the savings you accrued, so it needs to be calculated into long-term ROI. From a contract standpoint, as mentioned, you must ensure you didn’t violate any “all or nothing” support clauses when you left – careful planning is required for partial transitions. Finally, some organizations perceive a risk to the relationship with Oracle. Leaving support might strain interactions with Oracle’s account team if you rely on Oracle for other things (like cloud services or strategic partnerships). This is usually manageable, but it’s a consideration for CIOs with broad engagements with Oracle beyond just software support.
In weighing these trade-offs, consider the profile of your Oracle environment and business needs. If your environment is stable, with infrequent changes, and high cost pressure, third-party support can be a strategic fit to reduce cost and risk (by avoiding disruptive upgrades). If your environment is rapidly evolving, or you plan major Oracle upgrades/expansions, staying with Oracle might be the safer route. It’s not an all-or-nothing decision either – some organizations adopt a hybrid model, keeping critical systems on Oracle support while moving others to third-party support. This segmented approach can optimize costs on legacy systems while still leveraging Oracle for systems tied to future innovation. However, Oracle’s contractual policies may limit mixing support within the same product line, so any hybrid strategy should be reviewed legally. The bottom line is that both options entail managing risk: with Oracle support, the risk is largely financial and in forced change, whereas with third-party support, the risk is in security (mitigated by the provider’s solutions) and license compliance. A CIO’s job is to balance these and choose the support strategy that best aligns with the organization’s tolerance for change, budget constraints, and innovation goals.
Recommendations for CIOs
If you are a CIO evaluating or implementing third-party support for Oracle, consider the following best practices and next steps to ensure security and compliance are maintained:
- Thoroughly Audit Your Oracle Licenses and Contracts: Before switching, review your Oracle license entitlements and support agreements. Ensure you understand clauses like the matching service level policy or license set rules that could affect your move. Remediate any license over-deployment or compliance issues while still under Oracle’s umbrella. This due diligence will prevent legal surprises later and provide a clean baseline for the third-party support period.
- Choose a Reputable, Security-Focused Provider: Not all third-party support vendors are equal. Investigate the security and compliance capabilities of any provider you consider. Ask for their security program details – do they have ISO 27001 or SOC 2 certification? What is their process for developing “virtual patches” or critical fixes? Inquire if they have ever had a client security breach tied to a missed Oracle patch (top providers can point to a spotless record here). Also, verify they offer support for regulatory updates relevant to your industry (e.g., tax and legal changes for ERP systems). A strong provider should readily supply references from similar clients and have a proven track record you can trust.
- Develop a Security & Patching Strategy: Work with the third-party provider to create a clear vulnerability management plan for your Oracle systems. Document how new vulnerabilities will be identified, how and when fixes or mitigations will be applied, and who is responsible for each step. Implement any additional internal controls needed – for example, you might deploy extra network intrusion detection or tighter firewall rules around the Oracle systems to complement the provider’s measures. Ensure your incident response plan is updated to include the third-party provider: you should know how to contact them in a security emergency, and their response commitment. By having a well-defined strategy, you maintain confidence that security will not slip through the cracks.
- Maintain Compliance Continuity: If you operate in a regulated sector, update your compliance documentation to reflect the new support model. Ensure that for every regulatory requirement (whether it’s GDPR data handling, HIPAA security rule, SOX IT controls, etc.), you can map how it’s being satisfied with the third-party in place. For instance, if auditors expect regular patching, be prepared to show evidence of the alternative fixes or compensating controls you use. Retain all communications and advisories from the support provider as part of your audit trail. It’s also advisable to formally notify internal audit and risk management departments about the support change so they can include it in audit scopes. Transparency and documentation will go a long way to reassuring stakeholders that compliance is managed.
- Plan for a Transition (and Possible Contingency): Don’t rush the cutover. Plan the transition during a low-activity period and involve your internal IT staff deeply so that knowledge transfer occurs. You might start with a non-production environment or a less critical system as a pilot to get familiar with the provider’s process. Also, consider a contingency plan for critical situations: for example, if an extreme severity issue arises that the third-party cannot fix fast enough, decide in advance if you would approach Oracle for a one-time fix or perhaps have a support arrangement for just that scenario. While such cases are rare, having a contingency agreement (even if it means budgeting for a potential Oracle re-support cost) can provide extra confidence. Many firms never need to invoke this, but it is comforting to have thought it through. Over time, as the third-party relationship proves itself, you can relax such contingencies, but initially, it’s a prudent safety net.
- Foster an Ongoing Partnership: Treat the third-party support provider as a strategic partner, not just a vendor to “set and forget.” Schedule regular governance meetings to review open issues, upcoming risks, and satisfaction with support levels. Keep the lines of communication open between your organization’s experts and the provider’s team – this encourages knowledge sharing that can further improve security and performance. By maintaining a close partnership, the provider can better understand your environment and compliance needs, and you can hold them accountable to commitments. This collaborative approach will ensure that you truly reap the benefits of third-party support (cost savings, stability, flexibility) without sacrificing security or compliance. Remember, the goal is to improve your IT support experience in all dimensions; staying engaged as an executive sponsor of this relationship is key to making that happen.
