CSL - Module 06
CSL - Module 06
CSL - Module 06
SOX:
The Sarbanes Oxley Act of 2002 (SOX) requires that a publicly-traded company maintain
transparency in financial reporting, preventing fraudulent accounting activities, and protecting
investors and improving investor confidence.
The Act includes sections about external auditors, corporate governance, internal control
assessments, and financial disclosures.
When it comes to IT, SOX requires firms to have policies and procedures that prevent, detect,
and disclose cybersecurity risks and incidents that are considered material likely to be
significant.
We live in a digital world. Our communications, transactions, and day-to-day workflows all
happen within a digital enterprise. Companies rely on advancements in technology to support
current and future business initiatives.
Rapidly evolving technology brings increased rewards and more responsibility to manage
cybersecurity risks.
The cause of cybersecurity risks can range from technological and procedural weaknesses to
human error.
To maintain security, compliance, and a competitive edge, businesses need to keep pace with the
ever changing nature of the digital marketplace.
Companies need to prove that they have data safeguards, and procedures ensuring those
safeguards are operational.
This includes quality access management, preventative security measures, as well as redundant
and secure backups.
Security systems must be able to detect data breaches, and the organization needs a
communication plan for notifying leadership and investors of identified breaches.
In reporting and during an annual audit, businesses must attest to and provide evidence that these
internal controls exist.
“About 90% of known cyber incidents at public companies went undisclosed in regulatory
filings in 2018,” according to the Wall Street Journal , who cited data from the Securities and
Exchange Commission (SEC).
Businesses are responsible for reporting material cybersecurity risks in a timely manner. This can
mean that an organization must disclose a risk or incident before regular reporting or an yearly
audit.
The SEC published the Commission Statement and Guidance on Public Company Cybersecurity
Disclosures to provide guidance on disclosures that involved cybersecurity risks and incidents.
SOX requires signing officer(s), typically an Executive Officer or Financial Officer, to attest that
the information in their internal control and financial reports are accurate.
They cannot contain any false statements, nor can they omit material information. They also
need documentation demonstrating that the organization is SOX compliant.
How do you know what your material cybersecurity risks and incidents are? How do you know if
you’ve experienced a breach?
If you are periodically reviewing alerts, you may miss the context or severity of threats.
If your IT team does not have the expertise to analyze risks, they may not see correlations that
signify a material risk.
Businesses may not report minor security incidents deeming them to be immaterial.
What if all these smaller threats and incidents turn out to be a much larger problem?
Unable to see the connection between events, an organization could unintentionally omit a
material cybersecurity risk in their reporting.
Even worse, it can lead to a security breaches, data loss, and damages.
To truly understand the risks in your environment, you need to monitor your network
continuously.
You also need the expertise and systems for evaluating and conducting a risk assessment.
With such high penalties for failure to appropriately disclose material cybersecurity risks and
incidents, it’s critical your business processes include a compliance process and a system of risk
management to identify and assess threats across your network.
In the age of digital transformation, periodic reviews of your environment are not enough.
Business entities need to monitor their network around the clock.
Performance monitoring lets you know if systems are operating efficiently, but it doesn’t tell you
what security threats exist or the severity of those risks.
With a pandemic increasing the number of malicious cyberattacks and technology changing
daily, it’s no longer acceptable to run occasional cybersecurity scans and assume you’re seeing
an accurate picture of your overall security posture.
To have a complete understanding of the risks and incidents that occur on your network, you
need 24x7x365 activity monitoring.
With a managed detection and response (MDR) service like CoreArmor , a team of security
analysts with skills in forensic analysis are able to identify, evaluate, and provide a response plan
to threats and breaches within your network.
GLBA:
The Gramm-Leach-Bliley Act (GLB Act or GLBA) is also known as the Financial
Modernization Act of 1999. It is a United States federal law that requires financial institutions to
explain how they share and protect their customers’ private information. To be GLBA compliant,
financial institutions must communicate to their customers how they share the customers’
sensitive data, inform customers of their right to opt-out if they prefer that their personal data not
be shared with third parties, and apply specific protections to customers’ private data in
accordance with a written information security plan created by the institution.
The primary data protection implications of the GLBA are outlined in its Safeguards Rule, with
additional privacy and security requirements issued by the FTC’s Financial Privacy Rule, created
under the GLBA to drive implementation of GLBA requirements. The GLBA is enforced by the
FTC, the federal banking agencies, and other federal regulatory authorities, as well as state
insurance oversight agencies.
The act has three main sections, consisting of two rules and a set of provisions. The term “3
rules” seems to have been adopted to help people better understand the requirements of the
legislation.
Each of these three measures are designed to inform and guide organizations covered by the
legislation about:
Financial Privacy Rule: A company that is either a “financial institution” or receives “nonpublic
personal information (NPI)” regarding consumers from a financial institution must adhere to the
privacy rule of the GLBA. This rule covers most personal information (name, date of birth,
Social Security number, etc.) as well as transactional data (card, bank account numbers). It also
covers private information you may acquire during a transaction (a credit report, for instance).
The FTC has a page detailing every aspect of the privacy rule, right here.
Safeguards Rule: This rule ensures that those under the jurisdiction of the GLBA have specific
means to protect private information. According to the text of the rule itself, GLBA adherents
must have “the administrative, technical, or physical safeguards you use to access, collect,
distribute, process, protect, store, use, transmit, dispose of, or otherwise handle customer
information.” Many of these techniques are outlined in the text as well.
● Employee training
● Proper software
● Testing and monitoring of vulnerabilities
Complying with the GLBA puts financial institutions at lower risk of penalties or reputational
damage caused by unauthorized sharing or loss of private customer data. There are also several
privacy and security benefits required by the GLBA Safeguards Rule for customers, some of
which include:
Compliance with the GLBA protects consumer and customer records and will therefore help to
build and strengthen consumer reliability and trust. Customers gain assurance that their
information will be kept secure by the institution. Safety and security cultivate customer loyalty,
resulting in a boost in reputation, repeat business, and other benefits for financial institutions.
The GLBA requires that financial institutions act to ensure the confidentiality and security of
customers’ “nonpublic personal information,” or NPI. Nonpublic personal information includes
Social Security numbers, credit and income histories, credit and bank card account numbers,
phone numbers, addresses, names, and any other personal customer information received by a
financial institution that is not public. The Safeguards Rule states that financial institutions must
create a written information security plan describing the program to protect their customers’
information. The information security plan must be tailored specifically to the institution’s size,
operations, and complexity, as well as the sensitivity of the customers’ information. According to
the Safeguards Rule, covered financial institutions must:
In order to achieve GLBA compliance, the Safeguards Rule requires that financial institutions
pay special attention to employee management and training, information systems, and security
management in their information security plans and implementation.
Once a GLBA non-compliance allegation is proven, the punishment can have business-altering,
and even life-altering, ramifications.
● Financial institutions found in violation face fines of $100,000 for each violation.
● Individuals in charge found in violation face fines of $10,000 for each violation.
Since the Act went into effect, there have been several allegations, including:
● PayPal (operating as Venmo) allegedly violated both the Federal Trade Act and the
GLBA. According to one source, “The FTC also asserts that the privacy practices it
alleges violate the GLBA and its Privacy Rule, and that the security failures it alleges
violate the GLBA and the Safeguarding Rule.”
● Early in the Act’s existence, the FTC invoked the GLBA against several mortgage
companies for a number of violations.
● In 2020, the FTC announced a complaint and settlement against Mortgage Solutions FCS,
doing business as Mount Diablo Lending, and the company’s owner, alleging that the
company posted sensitive personal and financial information from individuals’ mortgage
applications and credit reports in response to negative Yelp reviews posted by customers
and applicants.
The main focus of the GLBA is to expand and tighten consumer data privacy safeguards and
restrictions. The primary concern, related to the GLBA, of IT professionals and financial
institutions is to secure and ensure the confidentiality of customers’ private and financial
information. Maintaining GLBA compliance is critical for any financial institution, as violations
can be both costly and detrimental to continued operations. However, by taking steps to
safeguard NPI and comply with the GLBA, organizations will not only benefit from improved
security and the avoidance of penalties, but also from increased customer trust and loyalty.
HIPAA:
The Health Insurance Portability and Accountability Act (HIPAA) sets the standard for sensitive
patient data protection. Companies that deal with protected health information (PHI) must have
physical, network, and process security measures in place and follow them to ensure HIPAA
Compliance. Covered entities (anyone providing treatment, payment, and operations in
healthcare) and business associates (anyone who has access to patient information and provides
support in treatment, payment, or operations) must meet HIPAA Compliance. Other entities,
such as subcontractors and any other related business associates must also be in compliance.
According to the U.S. Department of Health and Human Services (HHS), the HIPAA Privacy
Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes
national standards for the protection of certain health information. Additionally, the Security
Rule establishes a national set of security standards for protecting specific health information
that is held or transferred in electronic form.
The Security Rule operationalizes the Privacy Rule’s protections by addressing the technical and
nontechnical safeguards that covered entities must put in place to secure individuals’ electronic
PHI (e-PHI). Within HHS, the Office for Civil Rights (OCR) is responsible for enforcing the
Privacy and Security Rules with voluntary compliance activities and civil money penalties.
HHS points out that as health care providers and other entities dealing with PHI move to
computerized operations, including computerized physician order entry (CPOE) systems,
electronic health records (EHR), and radiology, pharmacy, and laboratory systems, HIPAA
compliance is more important than ever. Similarly, health plans provide access to claims as well
as care management and self-service applications. While all of these electronic methods provide
increased efficiency and mobility, they also drastically increase the security risks facing
healthcare data.
The Security Rule is in place to protect the privacy of individuals’ health information, while at
the same time allowing covered entities to adopt new technologies to improve the quality and
efficiency of patient care. The Security Rule, by design, is flexible enough to allow a covered
entity to implement policies, procedures, and technologies that are suited to the entity’s size,
organizational structure, and risks to patients’ and consumers’ e-PHI.
The HHS requires physical and technical safeguards for organizations hosting sensitive patient
data. These physical safeguards include…
Along the same lines, the technical safeguards of HIPAA require access control allowing only for
authorized personnel to access ePHI. Access control includes…
● Using unique user IDS, emergency access procedures, automatic log off, and encryption
and decryption
● Audit reports or tracking logs that record activity on hardware and software
Other technical policies for HIPAA compliance need to cover integrity controls, or measures put
in place to confirm that ePHI is not altered or destroyed. IT disaster recovery and offsite backup
are key components that ensure that electronic media errors and failures are quickly remedied so
that patient health information is recovered accurately and intact. One final technical safeguard is
network, or transmission security that ensures HIPAA compliant hosts protect against
unauthorized access to ePHI. This safeguard addresses all methods of data transmission,
including email, internet, or private networks, such as a private cloud.
To help ensure HIPAA compliance, the U.S. government passed a supplemental act, The Health
Information Technology for Economic and Clinical Health (HITECH) Act, which raises
penalties for health organizations that violate HIPAA Privacy and Security Rules. The HITECH
Act was put into place due to the development of health technology and the increased use,
storage, and transmission of electronic health information.
DATA PROTECTION FOR HEALTHCARE ORGANIZATIONS AND MEETING HIPAA
COMPLIANCE
The need for data security has grown with the increase in the use and sharing of electronic
patient data. Today, high-quality care requires healthcare organizations to meet this accelerated
demand for data while complying with HIPAA regulations and protecting PHI. Having a data
protection strategy in place allows healthcare organizations to:
● Ensure the security and availability of PHI to maintain the trust of practitioners and
patients
● Meet HIPAA and HITECH regulations for access, audit, integrity controls, data
transmission, and device security
● Maintain greater visibility and control of sensitive data throughout the organization
The best data protection solutions recognize and protect patient data in all forms, including
structured and unstructured data, emails, documents, and scans, while allowing healthcare
providers to share data securely to ensure the best possible patient care. Patients entrust their data
to healthcare organizations, and it is the duty of these organizations to take care of their protected
health information. To learn more about best practices for healthcare data protection, read our
guide to healthcare cybersecurity.
It’s an understatement to say the world is different due to the pandemic. Healthcare is, almost
undoubtedly, set to change the most over the next several years. Maintaining privacy compliance
is also more difficult. Factors increasing the risk of private health information include:
● Telehealth Visits: The number of healthcare provider visits conducted over the web has
skyrocketed. Patients who typically make short trips to the clinic or office decide to stay
home and see their physician virtually, unless an in-person visit is absolutely necessary.
Data protection over the Internet is difficult if proper precautions are overlooked.
● Increased Patient Count (post-lockdown): Now that many states allow most procedures
and visits to occur, there has been an onslaught of appointments. When paired with
physical distancing guidelines, offices are often short on staff when schedules are maxed
out. This situation creates an opportunity for HIPAA compliance mistakes.
● Multiple Care Providers: Patients often see multiple doctors. However, increased testing
and varied result times make things cloudy. Primary care physicians receiving updates
from multiple testing labs, patients, or hospitals means data is moving in and out at a
faster pace (if dealing with potential virus cases).
“A covered health care provider that wants to use audio or video communication technology to
provide telehealth to patients during the COVID-19 nationwide public health emergency can use
any non-public facing remote communication product that is available to communicate with
patients. OCR is exercising its enforcement discretion to not impose penalties for
noncompliance with the HIPAA Rules in connection with the good faith provision of telehealth
using such non-public facing audio or video communication products during the COVID-19
nationwide public health emergency. This exercise of discretion applies to telehealth provided
for any reason, regardless of whether the telehealth service is related to the diagnosis and
treatment of health conditions related to COVID-19.” (Source: HHS)
Make sure to follow these updates from those who monitor and enforce HIPAA compliance in
order to ensure the safest environment. Communications are likely to provide guidance on the
most prominent issues caused by the pandemic, such as increased appointments, data threats, and
mitigation techniques.
A number of changes and updates to HIPAA are being considered and may become either
guidance or parts of the law within the coming months.
Potential fines and penalties were updated earlier in 2019. (The official documentation was
scheduled to be published on April 30th.) Details outlined in the document included a tiered
structure for violations with corresponding “caps” now starting from $25,000 for Tier 1.
2019 was a big year for enforcement. According to HIPAA Journal, the average financial penalty
was more than $1.2 million. Enforcement was increased in 2018 and obviously wasn’t slowed
this past year. The Health & Human Services Office for Civil Rights (HHS OCR) did tighten
enforcement efforts in 2018, obviously continuing through last year. However, due to the current
world situation, enforcement may take a backseat for most of 2020.
The status of opioid addiction and overuse in America has been prominently labeled as a “crisis”
and an “epidemic”. New legislation has been promised and debated to battle the issues
surrounding the controversial drug. However, it may cause further changes to HIPAA. These
changes could range from further guidance or potential compliance issues.
ISO:
ISO stands for International Organization for Standardization. International Standards make
things to work. These standards provide a world-class specification for products, services and
computers, to ensure quality, safety and efficiency. They are instrumental in facilitating
international trade.
The need of ISO 27000 series arises because of the risk of cyber-attacks which the organization
face. The cyber-attacks are growing day by day making hackers a constant threat to any industry
that uses technology.
The ISO 27000 series can be categorized into many types. They are-
ISO 27001- This standard allows us to prove the clients and stakeholders of any organization to
managing the best security of their confidential data and information. This standard involves a
process-based approach for establishing, implementing, operating, monitoring, maintaining, and
improving our ISMS.
ISO 27000- This standard provides an explanation of terminologies used in ISO 27001.
ISO 27002- This standard provides guidelines for organizational information security standards
and information security management practices. It includes the selection, implementation,
operating and management of controls taking into consideration the organization's information
security risk environment(s).
ISO 27005- This standard supports the general concepts specified in 27001. It is designed to
provide the guidelines for implementation of information security based on a risk management
approach. To completely understand the ISO/IEC 27005, the knowledge of the concepts, models,
processes, and terminologies described in ISO/IEC 27001 and ISO/IEC 27002 is required. This
standard is capable for all kind of organizations such as non-government organization,
government agencies, and commercial enterprises.
ISO 27032- It is the international Standard which focuses explicitly on cybersecurity. This
Standard includes guidelines for protecting the information beyond the borders of an
organization such as in collaborations, partnerships or other information sharing arrangements
with clients and suppliers.
FISMA:
The Federal Information Security Management Act (FISMA) is a United States federal law
passed in 2002 that made it a requirement for federal agencies to develop, document, and
implement an information security and protection program. FISMA is part of the larger
E-Government Act of 2002 introduced to improve the management of electronic government
services and processes.
FISMA is one of the most important regulations for federal data security standards and
guidelines. It was introduced to reduce the security risk to federal information and data while
managing federal spending on information security. To achieve these aims, FISMA established a
set of guidelines and security standards that federal agencies have to meet. The scope of FISMA
has since increased to include state agencies administering federal programs like Medicare.
FISMA requirements also apply to any private businesses that are involved in a contractual
relationship with the government.
In April 2010 the Office of Management and Budget (OMB) released guidelines which require
agencies to provide real time system information to FISMA auditors, enabling continuous
monitoring of FISMA-regulated information systems.
FISMA COMPLIANCE REQUIREMENTS
The National Institute of Standards and Technology (NIST) plays an important role in the
FISMA Implementation Project launched in January 2003, which produced the key security
standards and guidelines required by FISMA. These publications include FIPS 199, FIPS 200,
and the NIST 800 series.
● Information System Inventory: Every federal agency or contractor working with the
government must keep an inventory of all the information systems utilized within the
organization. In addition, the organization must identify the integrations between these
information systems and other systems within their network.
● Risk Categorization: Organizations must categorize their information and information
systems in order of risk to ensure that sensitive information and the systems that use it are
given the highest level of security. FIPS 199 “Standards for Security Categorization of
Federal Information and Information Systems” defines a range of risk levels within which
organizations can place their various information systems.
● System Security Plan: FISMA requires agencies to create a security plan which is
regularly maintained and kept up to date. The plan should cover things like the security
controls implemented within the organization, security policies, and a timetable for the
introduction of further controls.
● Security Controls: NIST SP 800-53 outlines an extensive catalog of suggested security
controls for FISMA compliance. FISMA does not require an agency to implement every
single control; instead, they are instructed to implement the controls that are relevant to
their organization and systems. Once the appropriate controls are selected and the
security requirements have been satisfied, the organizations must document the selected
controls in their system security plan.
● Risk Assessments: Risk assessments are a key element of FISMA’s information security
requirements. NIST SP 800-30 offers some guidance on how agencies should conduct
risk assessments. According to the NIST guidelines, risk assessments should be
three-tiered to identify security risks at the organizational level, the business process
level, and the information system level.
● Certification and Accreditation: FISMA requires program officials and agency heads to
conduct annual security reviews to ensure risks are kept to a minimum level. Agencies
can achieve FISMA Certification and Accreditation (C&A) through a four-phased
process which includes initiation and planning, certification, accreditation, and
continuous monitoring.
Companies operating in the private sector – particularly those who do business with federal
agencies – can also benefit by maintaining FISMA compliance. This can give private companies
an advantage when trying to add new business from federal agencies, and by meeting FISMA
compliance requirements companies can ensure that they’re covering many of the security best
practices outlined in FISMA’s requirements.
For those government agencies or associated private companies that fail to comply with FISMA
there are a range of potential penalties including censure by congress, a reduction in federal
funding, and reputational damage.
Obtaining FISMA compliance doesn’t need to be a difficult process. The following are some best
practices to help your organization meet all applicable FISMA requirements. While this list is not
exhaustive, it will certainly get you on the way to achieving FISMA compliance.
NERC:
NERC is the North American Electric Reliability Corporation. NERC was founded in the late
1960s as the National Electric Reliability Council in response to the northeastern U.S. blackouts
of the early and mid-’60s, as the need for utility cooperation became more apparent. The
organization was quickly renamed to encompass “North America” as the integrated nature of the
joint U.S./Canadian power grid made the need for cross-border cooperation clear.
NERC is a non-profit body created and funded by the utilities themselves. It is subject to the
Federal Energy Regulatory Commission, the United States government’s regulatory entity for
energy. The original creation of NERC was to focus on the stability and reliability of the grid
after a significant blackout on the east coast of North America during the 1960s.
Over time, NERC worked with utility experts to create voluntary standards for operations for the
industry, and those standards were highly influential in the establishment of stability within the
North American power grid throughout the 1980s and 1990s.
As the need for protection of the national infrastructure, in general, became more apparent in the
late 1990s, triggering a Presidential Decision Directive from President Clinton in 1996, NERC
shifted to focus on issues of cyber security, along with some consideration of physical security
for issues that could have an impact on interstate commerce.
Discussions around the consideration of the creation of a set of cyber security standards for the
industry began when the catalyzing events of 9/11/2001 occurred and provided an increased
sense of urgency to the effort. Timelines were compressed by several years from what
participants at the time had expected, and NERC issued an Urgent Action Standard in 2003
which served as the predecessor of the current CIP standards.
In conjunction with that timeline, a significant outage in the northeastern US, Ontario, and
Quebec in 2003 led to calls and eventually action to strengthen the responsibilities of asset
owners and operators to follow the NERC standards. Under the Energy Policy Act of 2005,
NERC was designated as the official Electric Reliability Operator (ERO) for the US power grid,
to be managed with some restrictions by the Federal Energy Regulatory Commission (FERC),
and NERC standards were given mandatory status, with the ability for NERC to issue fines with
FERC approval. While most fines are in the low five-figure range, fines of over a million dollars
have been issued for systemic series of violations.
NERC standards are created by drafting teams composed of industry experts, often based upon
general directives issued by FERC staff, and are subjected to multiple rounds of review and
comment before being voted on and, usually, approved by the NERC membership, the NERC
Board of Trustees, and the FERC commissioners.
NERC standards belong to family groups which are reflected in their names. For example, the
BAL standards cover required activity by what is called Balancing Authorities, who balance the
power generation needs within a region, and the MOD standards cover required modeling
activity by transmission and generation operators. The CIP standards are named for the effort for
Critical Infrastructure Protection, a general term that arose in the aftermath of the original
Clinton Directive.
The first version of the CIP standards was released in 2006 and approved by the Federal Energy
Regulatory Commission in 2008. That core body of standards went through what are generally
considered to be five versions before revision numbering was abandoned for the body as a whole
in favor of tracking versions of individual standards. Versions 3 and 5 represented significant
steps forward for the industry as a whole. With the change to per-standard revision monitoring,
incremental changes such as the addition of a supply chain security standard and consideration
for better support for virtualization have been possible.
Standard Topic
Although all of these standards are important and can result in fines if not met, there are a few
which warrant further detail and understanding.
PCI:
The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements intended
to ensure that all companies that process, store, or transmit credit card information maintain a
secure environment. It was launched on September 7, 2006, to manage PCI security standards
and improve account security throughout the transaction process. An independent body created
by Visa, MasterCard, American Express, Discover, and JCB, the PCI Security Standards Council
(PCI SSC) administers and manages the PCI DSS. Interestingly, the payment brands and
acquirers are responsible for enforcing compliance, rather than the PCI SSC.
In order to provide an extensive resource on PCI compliance, this article includes:
● A detailed overview of PCI SSC Data Security Standards (along with multiple resources
for further review).
● The 12 requirements of PCI DSS Compliance listed out and explained.
● Benefits of PCI Compliance.
● Potential setbacks of being non-compliant.
● A roundup of collected tips from 18 PCS DSS experts.
In an effort to enhance payment card data security, the PCI Security Standards Council (SSC)
provides comprehensive standards and supporting materials, which include specification
frameworks, tools, measurements, and support resources to help organizations ensure the
security of cardholder information at all times. The PCI DSS is the cornerstone of the council, as
it provides the necessary framework for developing a complete payment card data security
process that encompasses prevention, detection, and appropriate reaction to security incidents.
Firewalls essentially block access of foreign or unknown entities attempting to access private
data. These prevention systems are often the first line of defense against hackers (malicious or
otherwise). Firewalls are required for PCI DSS compliance because of their effectiveness in
preventing unauthorized access.
The third requirement of PCI DSS compliance is a two-fold protection of cardholder data. Card
data must be encrypted with certain algorithms. These encryptions are put into place with
encryption keys — which are also required to be encrypted for compliance. Regular maintenance
and scanning of primary account numbers (PAN) are needed to ensure no unencrypted data
exists.
Cardholder data is sent across multiple ordinary channels (i.e., payment processors, home office
from local stores, etc.). This data must be encrypted whenever it is sent to these known locations.
Account numbers should also never be sent to locations that are unknown.
Installing anti-virus software is a good practice outside of PCI DSS compliance. However,
anti-virus software is required for all devices that interact with and/or store PAN. This software
should be regularly patched and updated. Your POS provider should also employ anti-virus
measures where it cannot be directly installed.
Firewalls and anti-virus software will require updates often. It is also a good idea to update every
piece of software in a business. Most software products will include security measures, such as
patches to address recently discovered vulnerabilities, in their updates, which add another level
of protection. These updates are especially required for all software on devices that interact with
or store cardholder data.
Cardholder data is required to be strictly “need to know.” All staff, executives, and third parties
who do not need access to this data should not have it. The roles that do need sensitive data
should be well-documented and regularly updated — as required by PCI DSS.
Any cardholder data must be physically kept in a secure location. Both data that is physically
written or typed and data that is digitally-kept (e.g., on a hard drive) should be locked in a secure
room, drawer, or cabinet. Not only should access be limited, but anytime the sensitive data is
accessed, it should be kept in a log to remain compliant.
All activity dealing with cardholder data and primary account numbers (PAN) require a log entry.
Perhaps the most common non-compliance issue is a lack of proper record keeping and
documentation when it comes to accessing sensitive data. Compliance requires documenting how
data flows into your organization and the number of times access is needed. Software products to
log access are also needed to ensure accuracy.
All ten of the previous compliance standards involve several software products, physical
locations, and likely a few employees. There are many things that can malfunction, go out of
date, or suffer from human error. These threats can be limited by fulfilling the PCI DSS
requirement for regular scans and vulnerability testing.
Inventory of equipment, software, and employees that have access will need to be documented
for compliance. The logs of accessing cardholder data will also require documentation. How
information flows into your company, where it is stored, and how it is used after the point of sale
will also all need to be documented.
Complying with PCI Security Standards seems like a daunting task, at the very least. The maze
of standards and issues seems like a lot to handle for large organizations, let alone smaller
companies. Yet, compliance is becoming more important and may not be as troublesome as you
assume, especially if you have the right tools.
According to PCI SSC, there are major benefits of compliance, especially considering that
failure to comply may result in serious and long-term consequences. For example:
● PCI Compliance means that your systems are secure, and your customers can trust you
with their sensitive payment card information; trust leads to customer confidence and
repeat customers.
● PCI Compliance improves your reputation with acquirers and payment brands – just the
partners your business needs.
● PCI Compliance is an ongoing process that aids in preventing security breaches and
payment card data theft in the present and in the future; PCI compliance means you are
contributing to a global payment card data security solution.
● As you try to meet PCI Compliance, you’re better prepared to comply with additional
regulations, such as HIPAA, SOX, and others.
● PCI Compliance contributes to corporate security strategies (even if only a starting
point).
● PCI Compliance likely leads to improving IT infrastructure efficiency.
PCI SSC also points to potentially disastrous results of failing to meet PCI Compliance. After
working to build your brand and secure customers, don’t take a chance with their sensitive
information. By meeting PCI Compliance, you are protecting your customers so they can
continue to be your customers. Possible results of PCI Non-Compliance include:
PCI Compliance, as with other regulatory requirements, can pose challenges to organizations that
are not prepared to deal with protecting critical information. But, protecting data is a much more
manageable task with the right software and services. Choose a data loss prevention software
that accurately classifies data and uses it appropriately so you can rest more easily knowing that
your cardholder data is secure.