Posts tagged "CCF"

SOC 2-Type 2 (Security & Availability) and ISO 27001:2013 Compliance Across All Adobe Enterprise Clouds

Posted on December 6, 2016 by | Comments (0)

We are pleased to report that Adobe has achieved SOC 2 – Type 2 (Security & Availability) and ISO 27001:2013 certifications for enterprise products within Adobe’s cloud offerings:

  • Adobe Marketing Cloud*
  • Adobe Document Cloud (incl. Adobe Sign)
  • Adobe Creative Cloud for enterprise
  • Adobe Managed Services*
    • Adobe Experience Manager Managed Services
    • Adobe Connect Managed Services
  • Adobe Captivate Prime
*(Excludes recent acquisitions including Livefyre and TubeMogul)

The criteria for these certifications have been an important part of the Common Controls Framework (CCF) by Adobe, a consolidated set of controls to allow Adobe teams supporting Adobe’s enterprise cloud offerings across the organization to meet the requirements of various industry information security and privacy standards.

As part of our ongoing commitment to help protect our customers and their data, and to help ensure that our standards effectively meet our customers’ expectations, we are constantly refining this framework based on industry requirement changes, customer asks, and internal feedback.

Following a number of requests from the security and compliance community, we are planning to publicly release an open source version of the CCF framework and guidance sometime in FY17 so that other companies may benefit from our experience.

Brad Arkin
Chief Security Officer

Security Automation for PCI Certification of the Adobe Shared Cloud

Posted on November 3, 2016 by | Comments (0)

Software engineering is a unique and exciting profession. Engineers must employ continuous learning habits in order to keep up with constantly morphing software ecosystem. This is especially true in the software security space.  The continuous introduction of new software also means new security vulnerabilities are introduced. The problem at its core is actually quite simple. It’s a human problem.  Engineers are people, and, like all people, they sometimes make mistakes.  These mistakes can manifest themselves in the form of ‘bugs’ and usually occur when the software is used in a way the engineer didn’t expect. When these bugs are left uncorrected it can leave the software vulnerable. Some mistakes are bigger than others and many are preventable. However, as they say, hindsight is always 20/20.  You need not necessarily experience these mistakes to learn from them. As my father often told me, a smart person learns from his mistakes, but a wise person learns from the mistakes of others. And so it goes with software security. In today’s software world, it’s not enough to just be smart, but you also need to be wise.

After working at Adobe for just shy of 5 years I have achieved the current coveted rank of ‘Black Belt’ in Adobe’s security program through the development of some internal security tools and assisting in the recent PCI certification of Shared Cloud (the internal platform upon which, Creative Cloud and Document Cloud are based).  Through Adobe’s security program my understanding of security has certainly broadened.  I earned my white belt within just a few months of joining Adobe which consisted of some online courses covering very basic security best practices. When Adobe created the role of “Security Champion” within every product team, I volunteered. Seeking to make myself a valuable resource to my team, I quickly eared my green belt which consisted of completing several advanced online courses covering a range of security topics from SQL Injection & XXS to Buffer Overflows. I now had 2 belts down,  only 2 to go.

At the beginning of 2015, the Adobe Shared Cloud team started down the path of PCI Compliance.  When it became clear that a dedicated team would be needed to manage this, myself and a few others made a career shift from software engineer to security engineer in order to form a dedicated security team for the Shared Cloud.  To bring ourselves up to speed, we began attending BlackHat and OWASP conferences to further our expertise. We also started the long, arduous task of breaking down the PCI requirements into concrete engineering tasks.  It was out of this PCI effort that I developed three tools – one of which would earn me my Brown Belt, and the other two my Black Belt.

The first tool came from the PCI requirement that requires you track all of 3rd party software libraries for vulnerabilities and remediate them based on severity. Working closely with the ASSET team we developed an API that would allow you to push product dependencies and versions into applications as they are built.   Once that was completed, I wrote an integrated and highly configurable Maven plugin which consumed the API during build time, thereby helping to keep applications up-to-date automatically as part of our continuous delivery system. After completing this tool, I submitted it as a project and was rewarded with my Brown Belt. My plugin has also been adopted by several teams across Adobe.

The second tool also came from a PCI requirement. It states that no changes are allowed on production servers without a review step, including code changes. At first glance this doesn’t seem so bad – after all we were already doing regular code reviews. So, it shouldn’t be a big deal, right? WRONG! The burden of PCI is that you have to prove that changes were reviewed and that no change was allowed to go to production without first being reviewed.  There were a number of manual approaches that one could take to meet this requirement. But, who wants the hassle and overhead of such a manual process? Enter my first Black Belt project – the Git SDLC Enforcer Plugin.  I developed a Jenkins plugin that ran with a merge onto a project’s release branch.  The plugin reviews the commit history and helps ensure that every commit belongs to a pull request and that each pull request was merged by someone other than the author of the pull request.  If any offending commits or pull requests are found then the build fails and an issue is opened on the project in its GitHub space.  This turned out to be a huge time saver and a very effective mechanism for ensuring every change done to the code is reviewed.

The project that finally earned me my Black Belt, however, was the development of a tool that will eventually fully replace the Adobe Shared Cloud’s secret injection mechanism. When working with Amazon Web Services, you have a little bit of a chicken and egg problem when you begin to automate deployments. At some point, you need an automated way to get the right credentials into the EC2 instances that your application needs to run. Currently the Shared Cloud’s secrets management leverages a combination of custom baked AMI’s, IAM Roles, S3, and encrypted data bags stored in the “Hosted Chef” service. For many reasons, we wanted to move away from Chef’s managed solution, and add some additional layers of security such as the ability to rotate encryption keys, logging access to secrets, the ability to restrict access to secrets based on environment and role, as well as making it auditable. This new tool was designed to be a drop in replacement for “Hosted Chef” – it made it easier to implement in our baking tool chain and replaced the data bag functionality provided by the previous tool as well as added some additional security functionality.  The tool works splendidly and by the end of the year the Shared Cloud will be exclusively using this tool resulting in a much more secure, efficient, reliable, and cost-effective mechanism for injecting secrets.

My take away from all this is that Adobe has developed a top notch security training program, and even though I have learned a ton about software security through it, I still have much to learn. I look forward to continue making a difference at Adobe.

Jed Glazner
Security Engineer

IT Asset Management: A Key in a Consistent Security Program

Posted on October 21, 2016 by | Comments (0)

IT Asset Management (ITAM) is the complete and accurate inventory, ownership and governance of IT assets. ITAM is an essential and often required stipulation of an organization’s ability to implement baseline security practices and become compliant with rigorous industry standards. As IT continues to transform, organizations face the challenge of maintaining an accurate inventory of IT assets that consist of both physical and virtual devices, as well as static and dynamic spin-up-spin-down cloud infrastructures.

The absence of ITAM can result in a lack of asset governance and inaccurate inventory. Without a formalized process, companies might unknowingly be exposed to insecure assets that are open to exploitation. On the contrary, proper ITAM helps enable organizations to leverage a centralized and accurate record of inventory in which security measures can be implemented and applied consistently across the organization’s environment.

Risks Without ITAM

Assets that are not inventoried and tracked in an ITAM program present a very real and critical risk to the business. Unknown assets seldom have an appropriate owner identified and assigned. In essence, nobody within the organization is owning the responsibility to ensure that the unknown asset is sufficiently governed or secured. As a result, unknown assets can quickly fall out of sync with regulatory or compliance requirements leaving them vulnerable for exploitation.

In a world of constant patches and hotfixes, an unknown asset can become vulnerable after only a single missed update. Bad actors rarely attack the well-known and security hardened asset. It is far more common for a bad actor to patiently traverse the organization’s network, waiting to attack until they have identified an asset which the organization itself doesn’t know exists.

Benefits of ITAM

Before a company can sufficiently implement programs designed to protect its operational assets, it must first have the ability to identify and inventory those assets. Companies should put into place processes and controls to automate the inventorying of assets obtained via procurement and virtual machine provisioning. Assets can be inventoried and continuously tracked using a Configuration Management Database (CMDB). Each asset can be inventoried in the CMDB and assigned an owner, who is responsible for asset governance and maintenance until the decommission, or destruction, of the asset.

Processes must also be put into place to continuously monitor and update the CMDB inventory. One example of how Adobe monitors its CMDB is by leveraging operating security controls. For example, Adobe performs an analysis to determine if all assets sending logs to a corporate log server are known assets inventoried in the CMDB. If the asset is not inventoried in the CMDB, then the asset is categorized as an unknown asset. Once unknown assets are identified, further analysis is performed so that the asset can be added to the CMDB and an appropriate owner assigned.

At Adobe, we have created the Adobe Common Controls Framework (CCF), which is a set of control requirements which have been rationalized from the complex array of industry security, privacy and regulatory standards. CCF provides the necessary controls guidance to assist teams with asset management. ITAM helps provide Adobe internal, as well as third party external, auditors a centralized asset repository to leverage in order to gain reasonable assurance that security controls have been implemented and are operating effectively across the organization’s environment.

As described above, maintaining a complete and accurate ITAM in an organization of any size is no easy task. However, when implemented correctly, the benefits of ITAM allow organizations to consistently apply security controls across the operating environment, helping result in a reduced attack surface for potential bad actors. If organizations are not aware of where their assets are, then how can they reasonably know what assets they need to protect?

Matt Carroll
Sr. Analyst, Risk Advisory and Assurance Services (RAAS)

 

Adobe’s CCF Helps Acquisitions Meet Security Compliance Requirements

Posted on August 8, 2016 by | Comments (0)

The Common Controls Framework (CCF) is a comprehensive set of control requirements, rationalized from the alphabet soup of several different industry information security and privacy standards. To help ensure that our standards effectively meet our customers’ expectations, we are constantly refining this framework based on industry requirement changes, customer asks, and internal feedback.

As Adobe continues to grow as an organization and as we continue to onboard new acquisitions, CCF enables these acquisitions to come into compliance more quickly. At Adobe, the goal is for acquisitions to meet organization security practices and standards and come up to speed with the compliance roadmap of the organization. CCF enables the new acquisitions to inherit existing simple & scalable solutions to reduce the overall effort significantly to meet compliance goals.

The journey for the newest members of the Adobe family (read: acquisition) begins with a gap assessment against the CCF. Once the gaps are determined against the existing CCF controls, the team can leverage a lot of driver-subscriber scalable controls (Read to understand driver-subscriber controls at Adobe) that are aligned with the CCF to remediate a majority of the gaps. Once the remediation is completed, often what is left is a handful of controls that need to be implemented in order to achieve compliance.

Another key component of security compliance is ensuring proper supporting documentation is in place. In most cases, the acquisition can therefore leverage existing documents used by product teams at Adobe that have successfully embarked and achieved compliance or on the roadmap, as they all address the same CCF requirements. Therefore, the team can often subscribe to the existing documentation when subscribing to a service. For the standalone controls, the teams can use existing templates documented in-line with the CCF to speed up the documentation effort.

Example of Implementation

One of our recent acquisitions was required to undergo PCI DSS compliance and as a result they underwent the gap assessment against the CCF controls. The acquisition was able to successfully leverage a lot of existing solutions like multifactor authentication to production, hardened baseline images, security monitoring, incident response processes to name a few to achieve compliance. At the end, the team was required to implement only a handful of standalone controls.

Given the new updated change in PCI DSS 3.2 around multifactor authentication, this acquisition will not be affected by the change in requirement as they already implemented Multi-factor authentication due to requirements listed in CCF.

Conclusion

Adobe’s CCF controls are helping new acquisitions achieve security compliance more quickly. These teams are able to leverage much of the existing infrastructure Adobe has put in place to meet and maintain its security certifications. Therefore, the overall burden of implementing these controls is significantly reduced and the acquisition that is now an Adobe member can continue to delight our customers at the same time as being compliant with Adobe’s security requirements.

Rahat Sethi
Sr. Information Security Analyst, Adobe Risk Assurance and Analysis Services (RAAS)

Identity and Access Management in the Enterprise Environment

Posted on July 19, 2016 by | Comments (0)

The management of identity is one of the most common and complex security challenges that is faced by organizations today. Many businesses operate globally with thousands of users constantly accessing hundreds of unique systems and applications. Establishing a role-based model and enforcing accountability is critical to securing access to company resources, but can be very difficult to implement, especially in mature and large organizations.

At Adobe, our Identity and Access Management (IAM) strategy is comprised of the following 6 pillars:

  1. Compliance with key Adobe Common Control Framework (CCF) objectives, especially those related to authentication and authorization.
  2. Authentication to Adobe systems is governed via a centralized identity source, which maintains compliance with scalable CCF requirements.
  3. Workflows have been implemented which automate provisioning, deprovisioning, and periodic access review processes.
  4. Access requests require a user and role to be selected from a pre-defined list, and a business justification must be provided.
  5. Once a user is granted access to a role, strong authentication is required to access company and customer resources.
  6. Critical system activity is logged to a centralized repository to maintain user accountability.

Our security administrators work diligently to discourage abuse and try to avoid human error. They recognize the importance of a centrally managed identity source built with strong role-based and accountability principles. When a single source of record exists, whose updates are automatically synced to all integrated systems, the need to manage access to each system independently is eliminated.

Workflows have been implemented to automatically route access requests to approvers, provision approved requests within the system, disable terminated users, and perform access updates based on periodic access review submissions. This automation helps reduce the risk associated with manual processes and creates efficiency in Adobe’s IAM implementation.

One of the most important pillars is defining a role-based access model. System owners predefine roles within Adobe’s automated provisioning workflow. This allows users to self-service the access request process while maintaining least privilege. Users requesting access to a role which would grant excessive privilege will be denied by the role owner and the user must resubmit their request for a more restrictive role.

Role-based models for managing access help reduce provisioning errors and overhead, improve logical access review accuracy, and enforce least privilege. When logical access roles are not defined, excessive or unauthorized access across systems is likely to result from manual and ad-hoc provisioning processes.

For example, without a defined role-based access model, new hires might require 25 separate permissions to be configured for them to perform their job responsibilities. Performing these tasks for numerous new hires, position transfers, and exiting personnel on a daily basis is cumbersome and prone to error.

Additionally, during periodic logical access reviews, the system owner must review each of the 25 separate permissions for every user with access to the system. The ability to review all users assigned to a defined role in one step will save the organization time and money while improving security.

On the other hand, defining a set of roles with explicit system privileges requires a one-time setup with minimal ongoing maintenance. Changes to existing roles should be controlled via change management processes. Once established, system owners can perform a single action to assign users to a role, or multiple roles, based on their job responsibilities.

Finally, least privilege requires that each defined and approved role has the minimum necessary system privileges which allow the role to fulfill its job requirements. When role creation is not guided by least privilege, it often results in excessive access for many of its members and appropriate access for very few of its members.  New roles should always be created for system users that require more or less access than what is provided by an existing role.

Mismanaged systems may introduce security and process breakdowns, which may facilitate unauthorized or excessive access to systems or data. Access to critical Adobe resources requires a valid whitelisted IP, username, password, and a logical access token or key. The combination of these elements comply with Adobe’s Authentication Standard requirements. If suspicious or malicious activity is identified within a system, security administrators are able identify the user and hold them accountable for their associated system activity.

Accountability ties the authenticated user to the actions they performed while interacting with the system. In most cases, a single user is assigned a unique account. When shared accounts are necessary, they must be individually authenticated to before being used by an individual user. This provides security administrators the ability to track a specific user’s actions within a system, which can be used to investigate incidents and deny repudiation.

Maintaining an efficient and more secure IAM model in a large organization can be challenging and requires diligent forethought. When implemented correctly, an organization can help reduce the risk and likelihood of unauthorized access, both internally and externally. Adobe is committed to excellence with the delivery of its services and the protection of both Adobe and customer resources. Our IAM implementation is just one of many examples of Adobe’s defense-in-depth security strategy.

Zosh Kuball
Sr. Analyst, Adobe Risk Assurance and Analysis Services (RAAS)

Adobe Document Cloud is now PCI DSS 3.1 compliant

Posted on July 12, 2016 by | Comments (0)

The Payment Card Industry Data Security Standard (PCI DSS) prescribes certain security controls for organizations that accept payments via credit card.  The standard is designed to help reduce fraud by increasing controls around cardholder data.

On June 30, 2016, Adobe Document Cloud (which includes Adobe Sign and PDF Services) achieved compliance with PCI DSS 3.1* as a merchant and a service provider.

The Adobe Document Cloud’s PCI compliant status as a service provider helps our customers meet PCI requirements for safe handling of cardholder data.

The Adobe Common Controls Framework (CCF) and the underlying Security Compliance strategy helped us meet the current PCI requirements.  Any changes to the PCI standard are proactively incorporated into the CCF to ensure on-going compliance for all Adobe businesses.

More information about our Common Controls Framework and compliance efforts can be found on Adobe.com.

Abhi Pandit
Sr. Director, Risk Advisory and Assurance Services (RaaS)

*Excludes Adobe Send & Track

Scaling Security Controls Across the Enterprise

Posted on May 31, 2016 by | Comments (0)

Adobe is changing the world through digital experiences. We do that in an incredibly creative and innovative environment where we also take our customers’ data security and privacy very seriously.  As a large and growing cloud company, achieving these things at the same time takes a sound strategy focused on two key pillars:

  • Establish Effective, Enforceable Security Standards
  • Implement and Adopt Simple, Scalable Security Services

Establish Effective, Enforceable Security Standards

The Common Controls Framework (CCF) is a comprehensive set of simple control requirements, rationalized from the alphabet soup of several different industry information security and privacy standards. To help ensure that our standards effectively meet our customers’ expectations, we are constantly refining this framework based on industry requirement changes, customer asks, and internal feedback.

In a recent update, Abhi Pandit (Adobe’s Sr. Director of Risk Advisory & Assurance Services) stated that “[Adobe] has made significant investments across the company to harmonize various security functions, compliance and governance processes, and technologies.” The CCF is the backbone of our corporate security policies and standards.

Implement and Adopt Simple, Scalable Security Services

With a common vision for customer data security and privacy set, we can look to our talented engineers to develop and implement the solutions that help meet our objectives.  Engineering teams collaborate to develop scalable solutions that implement the CCF requirements in the most efficient and elegant way possible. Other teams leverage those services and help improve them over time.

A common pitfall seen with initiatives like the CCF is that teams may try to implement all of the standards on their own with little or no reliance on cross-functional services. Not only does this undermine the entire purpose of a common standard, it can often result in some undesirable outcomes. Examples include:

  • Team resources overwhelmed by compliance initiatives and ability to deliver on product features may be hindered.
  • Standalone compliance initiatives only partly address requirements and security may be compromised.
  • Exhausted team resources lead to operational failure of compliance responsibilities and security may be compromised.

At Adobe, we make a concerted effort to help product teams use simple, scalable services to help prevent these undesirable outcomes. These services are a combination of internally developed services and reliable third party tools. Teams focus their effort on adopting those security services helping to free up their time to focus more on features that deliver a delightful, more secure user experience.

Practical Example of Implementation

Adobe uses four different types of control “roles” to organize our compliance efforts to meet the CCF standards: Driver, Subscriber, Contributor, and Standalone.

A driver is ultimately responsible for developing a service, including controls, that will mitigate a particular risk associated with a process and address the CCF requirements. For example, a driver implements a robust Identity Management system that can provide automated workflows for logical access control.

A subscriber is responsible to integrate their systems and processes in a way that will take advantage of the driver’s service. Continuing with the example above, a subscriber makes sure the only way to access their system is through the driver’s identity management system. As long as this continues, they share the risk with the driver.

A contributor is like a subscriber, integrated with a driver’s solution, but they may have a more active role in executing the control. A great example is a periodic access review. The driver’s identity management system gives contributors a notification that it’s time to review the access privileges in their respective groups so that they can certify the access is appropriate. They use a tool that makes it easy and effective—much easier and effective than a manual process that leverages a ticket or email.

If a team decided to tackle these problems as a standalone, they would need to set up their own identity management system or manual procedures to handle logical access control. These tend to be more manual and at a higher risk for control failure. The advantage of the CCF framework is these necessary core services and controls are provided and teams do not need to tackle these issues on their own, helping to lessen the overall risk.

The table below outlines a summary of these different roles and how they are currently viewed at Adobe.

Adobe CCF Control Roles

Role Business Objective Risk Responsibility
Driver Implement robust service for all teams to satisfy control requirements. Reduce instances of services to the minimum possible and improve the services over time. Mitigate
Subscriber Adopt robust service provided by Driver Transfer/Share
Contributor Leverage robust service provided by Driver and work with them to meet requirements Transfer/Share
Standalone Implement a process to satisfy control requirements. Reduce instances to the minimum possible. Mitigate

Conclusion

As Adobe grows, it is the hope that the number of compliance procedures should not grow at the same rate. The simple concepts explained in this post make up some of the secret sauce of how to leverage a compliance program to more effectively mitigate information security and privacy risk in a scalable way.

Kenny Scott
Manager, I.T. and Information Security, Risk Advisory and Assurance Services

Adobe CCF Enables Quicker Adherence to Updated PCI Standards

Posted on May 19, 2016 by | Comments (0)

The Adobe.com e-commerce store has been a PCI level 1 certified merchant for the last few years.  Adobe has significantly reduced its Card Holder Data environment (CDE) scope for this environment by using an external tokenization solution and maintains PAN-free environment by not storing any Primary Account Numbers (PAN) in its internal network. Adobe has implemented its Common Controls Framework (CCF) within the Card Holder Data environment which allows it to use the same set of controls to meet with requirements set forth by Payment Card Industry Data Security Standard PCI DSS V3.1 and many other security/compliance frameworks like ISO27001:2013, SOC2, among others. CCF is a set of approximately 250 controls designed specifically for Adobe’s business and provides the benefit by rationalizing the overlapping requirements across 10 different compliance and security frameworks.

PCI Security Standards Council (PCI SSC) recently released the latest version of the Data Security Standard V3.2. One of the notable changes in the PCI DSS V3.2 is the additional clarification provided around the use of multi-factor authentication for all administrative and remote access to the CDE.

PCI DSS V3.2 reference:

“8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.”

 By implementing CCF within the CDE, Adobe has already established a baseline control which requires all remote VPN sessions and production environments to be accessed via multi – factor authentication. This baseline control was adopted to meet with the requirements established by the more stringent of the compliance frameworks, hence allowing for Adobe to already be complaint with the clarifications provided in the PCI DSS v3.2 around multi-factor authentication.

Prasant Vadlamudi
Manager, Risk Advisory and Assurance Services (RAAS)

Marketing Cloud Gains New Compliance Wins

Posted on February 3, 2016 by | Comments (0)

Over the past couple of years, we have developed the Adobe Common Controls Framework (CCF), enabling our cloud products, services, platforms and operations to achieve compliance with various security certifications, standards, and regulations (SOC2, ISO, PCI, HIPAA, FedRAMP etc.).  The CCF is a cornerstone of our company-wide security strategy. The framework has gained acceptance and visibility across our businesses leading to a growing roster of certifications.

Last week, Adobe Marketing Cloud became compliant with SOC2 -Type 1. This certification also enables our financial institution customers to comply with the Gramm-Leach Bliley Act (GLBA) requirements for using service providers.

In addition to SOC2 – Type 1, Adobe Experience Manager Managed Services (AEM MS) and Adobe Connect Managed Services (AC MS) have achieved compliance with ISO27001.  AEM MS has also achieved compliance with HIPAA, now joining AC MS in this designation.  This is in addition to the recently confirmed FedRAMP certification for both of these solutions, achieved in 2015.

During 2015, the Document Cloud eSign service implemented the CCF as well and became compliant with SOC2-Type 2, ISO27001, PCI, and HIPAA requirements. Please refer to the “Adobe Security and Privacy Certifications” white paper on Adobe.com for the most up-to-date information about our certifications across our products and services.

Over the past 3 years, we have made significant investments across the company to harmonize various security functions, compliance and governance processes, and technologies. These are major accomplishments and milestones for Adobe’s cloud services and products which will allow us to provide our customers with assurance that their data and applications are more secure.

We have also been out in the security and compliance community, talking with information security and compliance professionals about CCF. This has enabled further collaboration with industry peers in this area. This is a all part of our on-going commitment to help protect our customers and their data. We will update you in future posts on this blog as we achieve additional compliance milestones.

Abhi Pandit
Sr. Director – Risk Advisory and Assurance

 

Meeting Compliance Challenges with Adobe CCF

Posted on October 27, 2015 by | Comments (0)

The Adobe Common Controls Framework (CCF) enables clear guidance to all of our product and services teams on how to secure our infrastructure and applications. We analyzed the criteria for the most common security certifications and found a number of overlaps. As a result, we were able to take over 1000 requirements from relevant cloud security frameworks and standards and rationalize them down to about 200 Adobe-specific controls. Control owners know exactly what is required to address expectations of stakeholders and customers when it comes to implementing those controls. It also supports more efficient implementation by allowing teams to inherit control capabilities as they are completed throughout the organization.

Watch as Abhi Pandit, our Senior Director for Governance, Risk, and Compliance (GRC), walks through the Adobe CCF, how it is helping us meet the compliance challenges we face in adhering to multiple standards and regulations, and learn how you can use a framework like CCF in your organization to assist with your own compliance challenges. You can learn more about CCF and Adobe’s progress in meeting various standards and regulations across our product lines in our white paper.