Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

Optimizing PCI compliance in financial institutions

In the fast-evolving world of finance, data security is of paramount importance. Financial institutions must ensure the protection of sensitive personal information, most commonly payment card data, to maintain, trust and meet various regulatory requirements. The Payment Card Industry Data Security Standard (PCI DSS) is a crucial framework to which financial institutions must adhere. However, managing PCI security compliance across various lines of business within these institutions can be a complex and resource-intensive task. 

This is where a Common Controls Assessment (CCA) can play a pivotal role. The CCA allows overarching enterprise functions and IT shared services to be assessed separately from the business unit’s products/applications that require PCI security compliance. 

How can implementing a CCA benefit financial institutions and their various business units in their quest for PCI security compliance?

CCA prerequisites

Large organizations usually govern their IT portfolio via global architectural patterns, which can be thought of as building blocks, and include IT security patterns. Some patterns are overarching and others are more precise, but regardless, they exist to standardize the IT environment by reducing the number of choices architects have to build a solution. That, in turn, reduces IT cost, the time it takes staff to learn the environment, and the time to market.

In practice, IT architectural patterns give architects the building blocks to design any IT solution. The architect chooses and orders the patterns available in the portfolio to meet the end goal. Having segmentation between infrastructure providing data processing and data storage is an example of a broad IT security architectural pattern. If the solution’s goal involves processing and storing data, the architect is constrained to place the pieces that will fulfill those tasks in the proper segments. Furthermore, if the operating system pattern is Linux Oracle Enterprise, the architect would use that pattern first in its design unless technical constraints made the consumption of this pattern suboptimal to accomplish the solution’s goal. All other needs, for example, authentication, encryption, log management, system configuration, would be treated the same—by using the architectural patterns available. 

The notion of pattern exists beyond IT in areas that a PCI security assessment touches, such as employee pre-employment practices, awareness security training, risk assessment methodology, or third-party service provider management. In fact, the scope of the CCA is the aggregation of the various IT and non-IT patterns that the enterprise uses in scope for PCI. As a result, the greater the number of redundant patterns (available solutions that provide the same result) used by an organization, the larger the CCA. For this reason, the existence of a relatively small number of architectural patterns is a prerequisite for a successful CCA. 

All solutions incorporate the architectural patterns tested through the CCA, which provides game-changing benefits, such as:

  • Combating compliance fatigue by testing the patterns only once instead of each time they are used
  • Streamlining assessments by delineating the PCI security responsibilities between the pattern used and the product using it, to which only having a subset of the PCI DSS requirements applies to each of them
  • Simplifying report writing by allowing assessors to refer to the CCA in the PCI Report on Compliance (ROC) 

Efficiency and resource optimization

The primary advantage of a CCA is that it streamlines the compliance efforts not only of the business units, but also of the teams delivering the security patterns for the organization. By identifying controls that are common to multiple departments—and which controls are delivered at the enterprise level—a CCA eliminates redundancy and ensures that resources are allocated efficiently.

One of the significant advantages of a CCA is the potential for cost reduction. Large financial institutions often consist of numerous business units, each of which may be subject to PCI security compliance requirements. Without a CCA, these units may conduct separate assessments and audits, leading to duplication of effort, audit fatigue and higher costs. Implementing a CCA allows the institution to consolidate assessments, often resulting in substantial cost savings.

Consistency and risk management

A security product/pattern might fulfill many security controls at the enterprise level. By assessing such security solutions using the CCA approach, all services provided are validated for compliance, which reduces the risk of compliance gaps and frees the business units to leverage additional security patterns from that solution without having to ensure that the solution is compliant. As an example of solutions that offer multiple security features/functionalities, think of the Identity and Access Management solutions. Some of them not only can provide strong authentication, but also have the ability to be used as a secret repository. As part of the CCA, the product is assessed for both of those features at once, freeing the business units to use one or both security patterns as their needs arise.

Simplified reporting

When it comes to PCI security compliance, reporting can be a time-consuming and intricate task. However, a CCA simplifies this process. The financial institution can provide a unified report that covers common controls, while individual business units only need to address their unique PCI DSS requirements. This simplification not only eases the reporting burden but also improves the clarity and accuracy of compliance reports.

Additionally, large financial institutions are often validated as service providers with large numbers of customers, all having to provide their own compliance results. As a result, large financial institutions may need to be included in their customers’ PCI assessments. Without a CCA, that service provider might have their security patterns assessed repeatedly, which could be a real security risk and could seriously strain financial institutions’ resources. 

Faster compliance and resource allocation

It’s often the case that speed is essential in the financial world. With a CCA in place, business units within a financial institution can achieve PCI security compliance more quickly. This is because business units don’t have to “reinvent the wheel” for common controls; instead, they can focus on addressing their unique requirements. The result is often a faster time-to-compliance, reducing exposure to potential security vulnerabilities.

A CCA can help business units substantially improve their resource allocation. When common controls are already established and documented, business units can allocate their resources more effectively. This efficiency allows them to concentrate on the aspects of PCI security compliance that are specific to their operations, ensuring a streamlined and cost-effective approach and increasing productivity of their resources.

CCA main challenge

The main challenge with having an effective CCA is its maintenance. As the technology portfolio changes, especially with the rapid adoption of the cloud, the architectural patterns included in the CCA have to be reevaluated periodically. This scoping exercise not only informs business leaders about the usage of each pattern and its applicability per environment (such as traditional servers, public/private cloud and mainframe) but also the PCI security requirements it fulfills on behalf of the enterprise in each environment. Developing a rigorous process for detecting and evaluating new architectural patterns is necessary for accurate reporting and ensuring full coverage of the PCI DSS within the financial institution. 

Practical example

Let’s imagine a large global financial institution with:

–       Products ranging from payment applications to payment gateway, to loyalty services, to fraud detection dispersed in many business units

–       Environments that include traditional data centers, private, public and hybrid clouds

–       Sizable number of vendors and service providers

–       Responsibility toward many regulatory frameworks across the globe, including localizations[1]

If a traditional approach to PCI security is taken, each product requiring PCI security compliance certification would include, as part of its assessment, the security controls delivered by the enterprise, such as identity and access management, multi-factor authentication, network connectivity, web application firewall, human resources processes, incident response, and the list goes on to cover all PCI DSS domains, all environments, and all relevant PCI DSS requirements—based on the use of those tools by the business units. In other words, every time a business unit is evaluated for PCI security compliance, the architectural patterns used to build the products that are in scope for PCI placing are also evaluated. This puts an extremely large and unsustainable compliance burden on the infrastructure teams, resulting in compliance fatigue for the resources. 

If a CCA existed in this environment, the teams providing answers to all of the security controls in the PCI DSS would have their own assessment and be evaluated for all the applicable requirements annually. The business teams would also be evaluated for PCI security compliance yearly, but only for the requirements applicable to their product and scope. The burden on the teams delivering the architectural patterns becomes manageable as validation is separated from the business unit assessment and is done at a convenient time.

Continuing with our example, from this large global financial institution, we can dive deeper into a fraud claim solution. This product/service is in-house developed that gets PCI data in batch via file transfer from issuers and acquirers and offers a graphical user interface for status on reported claims. This fraud claim detection solution stores the claims details in a database managed by the database administrator (DBA) team. It leverages an enterprise portal to display the claims details to users and integrates with internal evaluators that review and weigh in on the claims all the way through to potential chargeback. Knowing the PCI responsibility of the teams supporting this business unit, the subset of PCI DSS requirements in domain 3 (data purging), 6 (software development), 10 (generating and forwarding logs), and 11 (change detection on application containers) are in scope and can be answered entirely by the operational team and developers supporting this product. All the other requirements are covered in various CCA assessments. In this example, the less obvious requirements covered by the enterprise team are in domain 3, where encryption at rest is transparently provided by Oracle TDE and key rotation is implemented on a predictable schedule by the DBA team. Also less obvious is domain 4, where the encryption of data in transit is handled by upstream services, such as reverse proxies and load balancers, an enterprise web portal and a file transfer service. 

In terms of numbers of requirements, the load on the business unit assessments is significantly reduced. All requirements across all domains of the PCI DSS are accounted for and tested with the teams that can remediate in case of a deviation in compliance. As mentioned previously, the number of requirements assigned to the business units depends on the maturity of the enterprise security control and environments at large.

Conclusion

In the intricate world of finance, PCI security compliance is nonnegotiable. Financial institutions must adhere to the stringent PCI DSS to safeguard cardholder data and maintain trust. A Common Controls Assessment offers an invaluable tool to optimize compliance efforts across various lines of business and to the internal service providers of security patterns alike. Its benefits are numerous and far-reaching, from enhancing efficiency and resource allocation to ensuring consistency and reducing audit fatigue.

As financial institutions continue to evolve, the importance of robust data security practices cannot be overstated. A CCA is not only a cost-effective solution but also a strategic one, allowing financial institutions to meet their PCI security compliance requirements effectively and efficiently. By implementing a CCA, financial institutions can strengthen their security infrastructure, build trust with customers, and gain a competitive edge over other organizations—all of whom are vying for new business opportunities with customers in this fast-paced world. Learn more about Verizon’s PCI assessments here.

[1] A government might impose data protection policies that force global institutions to set up dedicated services in that country when data is hauled crossborder by these organizations for processing and storage in the past. For example, India, South Africa, and China have localization rules where the processing and storing of credit card information has to be done in the country (on soil).

Claire LaVelle is a principal consultant QSA for Verizon Cyber Security Consulting group. 

Data and Information Security
Read More from This Article: Optimizing PCI compliance in financial institutions
Source: News

Category: NewsJanuary 4, 2024
Tags: art

Post navigation

PreviousPrevious post:IT to thank for most of Radisson Hotel Group’s business initiativesNextNext post:Top 8 ways to improve cybersecurity for your organization

Related posts

Barb Wixom and MIT CISR on managing data like a product
May 30, 2025
Avery Dennison takes culture-first approach to AI transformation
May 30, 2025
The agentic AI assist Stanford University cancer care staff needed
May 30, 2025
Los desafíos de la era de la ‘IA en todas partes’, a fondo en Data & AI Summit 2025
May 30, 2025
“AI 비서가 팀 단위로 지원하는 효과”···퍼플렉시티, AI 프로젝트 10분 완성 도구 ‘랩스’ 출시
May 30, 2025
“ROI는 어디에?” AI 도입을 재고하게 만드는 실패 사례
May 30, 2025
Recent Posts
  • Barb Wixom and MIT CISR on managing data like a product
  • Avery Dennison takes culture-first approach to AI transformation
  • The agentic AI assist Stanford University cancer care staff needed
  • Los desafíos de la era de la ‘IA en todas partes’, a fondo en Data & AI Summit 2025
  • “AI 비서가 팀 단위로 지원하는 효과”···퍼플렉시티, AI 프로젝트 10분 완성 도구 ‘랩스’ 출시
Recent Comments
    Archives
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.