The Compliance and Audit Lifecycle of a People-First Security Program

In the beginning, back before digital transformation became another piece of tech jargon, IT administrators created passwords for their employees to log onto on-premises systems and networks. As they added more contract workers or external vendors, they provided them with passwords. 

The information systems triad of People-Process-Technology acts as a crutch for many. When problems arise, your first reaction may be to respond by creating a new policy that alleviates the problem. For example, when a data breach caused by a compromised password occurs, reaching for a password and authentication policy is a reflex. The gut reaction is to fix the process by changing the password requirements or adding another technology with multi-factor authentication. Problem solved. In reality, setting policy only works if the people in the organization understand the reason for these processes and technologies because a single CISO or CIO cannot manage the problem alone. To meet compliance requirements and protect data privacy, security professionals need to connect with their people so that they can create actionable policies enforce processes and document effectiveness to prove compliance.

When Processes Change, Policies Change

As you adopted cloud technologies like Software-as-a-Service (SaaS) applications, you needed to find ways to secure the remote identities. This change in process, changed how you managed your people. To secure access, you brought in a new technology – multi-factor authorization. This protected your SaaS applications from unauthorized users, or at least tried to. 

Today, people are not the only ones that need passwords for access to systems and networks.  Devices, applications, printers, service accounts, and automated robotic process automations all utilize passwords and, as with people, need multi-factor authentication to secure their access to and within your cloud infrastructures. 

This example highlights the thought process needed to write and implement effective policies. If policy writers think one step ahead, focus on the whole process not just react to a new event, the policies better match your organization’s needs. 

When The Prescriptive Models Create Audit Failures

Many of the first compliance models were based on prescriptive technologies. These industry standards and regulations, such as PCI DSS, HIPAA, ISO, or NIST, date back to the late 1990’s or early 2000’s, when most companies delivered IT through their on-premises architectures. The policies written to meet audit requirements were created with the auditor in mind. The IT auditors, hopefully more tech-savvy than the average employee, understood the terminologies, processes, and goals. However, the people affected by the policies often lacked context. 

This confusion led to countless meetings with stakeholders ranging from the c-suite to the standard employee to discuss what the policy means, who it applies to, and how implementing an enabling technology reduced risks involved. Many people affected by the change walk out of the meetings, shaking their heads, and saying, “I’ll just keep working as I have been and produce the same looking report when audit asks for it.”

Unfortunately, these prescriptive models take a long time to update. Creating policies and procedures based solely on their requirements does not protect the organization. In fact, your compliance with one prescriptive technology requirement may not meet another, risk-based or outcome based audit requirement. 

How to Base Your Policy on People

In some cases, the policy writer remains disconnected from the operational technology in use. In other cases, the audit staff only knows that at one point the company used a specific technology. The IT, compliance, and audit functions all operated independently from one another.  

However, if you update your  mindset to focus on a People-based policy, including thinking of your different internal departments as people-based not faceless monoliths, you can make your policies more effective and less prescriptive.

The baseline purpose of your policy is to effectively manage your solutions: tracking who accessed what resources, who managed those resources, who can provide detailed information about access, and who can detail the business impact if things go awry. Instead of thinking of compliance as a “task,” start thinking about it as a People-driven process.

To create a People-based security model, you can use Identity to help focus on three key components: purpose, key performance indicators, and auditable outcomes.

How to Define A Clear Purpose 

When you create a People-focused strategy, you start with the people and their behaviors, not the compliance standard or regulation. While that may seem counter-intuitive, the compliance requirements began because companies were not protecting people’s data. Their primary purpose is to require privacy and security. If you start from their purpose, you can define your own. 

Ask yourself the following questions:

Ques- That behaviour do we want to encourage with this policy?

Ans- Your policy is to protect your customers information, not to produce a report for an auditor.

Ques- Who are my stakeholders?

Ans- Identify the people that need to be involved, and realize that the scope of individuals involved is larger than you might realize. Keep focused on the business outcome.

Ques- What standards and regulations do I need to comply with?

 Ans- If you need to be PCI-DSS compliant say so. If you need to be HIPAA compliant as well, make sure you include that. This can help focus your audit scope.  

Ques- Who is responsible for the day-to-day management and enforcement of the policy?

Ans- Define the people responsible for managing the affected business solution.  For example, if you need to be PIC DSS compliant, you need to assign access rights to  the right systems and solutions, document the access requirements, and assign someone to enforce the access rights in the policy The people with  access to the data matter more to protecting the information than then people setting up the system; however but both sets of people play a role in delivering a safe solution

Can I explain this to everyone who needs to understand it? Enforcing a policy is easier when you communicate its importance to everyone in language they understand. For example, a policy for “Cisco VPN” usage is technically correct, but many people may recognize it more easily as the “Gold Lock Thing.” Communicating the policy to users and auditors may need different language. Less technical jargon can go a long way.

How to Make it Measurable

Policies set the rules, but you also need to make sure that you measure how well people are following the rules. To do this, you need to create key performance indicators. Some questions to ask include:

  • Are there specific measurements that can be attributed to each policy?  
  • Can you get a count from an automated system that tells you when there are policy violations? 
  • Can you get the number of times that policy actually gets utilized properly? 
  • How many policy exceptions are there?
  • How are we monitoring these exceptions to keep them current or to remove them?

How to Produce Audit Documentation

 The final step to creating a People-focused security program lies in documenting the entire process for your auditor. This documentation includes the risk assessment, policy, and your reports proving that the controls were effective. 

When trying to pull together your audit documentation, you want to include:

  • Logs showing all user activity, including your privileged users
  • Any minutes from meetings where you reviewed security events
  • Exceptions to the policy
  • Duration that the exception lasted
  • Proof that you reviewed all documentation to ensure policy enforcement

Automating the report generation can streamline the documentation process. Using an automated tool, you can prove governance and key performance indicators to verify your policy effectiveness. 

Saviynt’s IGA and Application Risk and Governance Solutions

When writing policies, you should always consider the audit lifecycle – from risk assessment through audit reporting. Identity and Access Governance is the key to creating a holistic People-based security program.  Automated solutions that govern the ownership of policies and controls provide the needed audit documentation. With automated tools that continuously monitor for anomalous access requests or use, you can prove continuous assurance over your program. 

With Saviynt’s Control Exchange, you have over 200 built-in controls to track access and usage, create key performance indicators, and streamline the compliance documentation process. 

Visibility into Who

Saviynt enables organizations to merge divergent identity, role, and group definitions from across its on-premise, hybrid, and cloud infrastructures to create a single, authoritative identity source. 

Visibility into What

Saviynt natively integrates with business critical IaaS and SaaS products. Using fine-grained access entitlements, organizations can limit access beyond the coarse-grained application level and drill down to the “edit/read” level. 

Visibility into Why

Saviynt’s analytics streamline the request/review/certify process by aligning with policy controls. The platform alerts users to anomalous requests/access which must be approved by an administrator. 

Visibility into How

Our peer- and usage-based analytics enable organizations to maintain “least privilege necessary” controls and prevent SOD violations. 

Joe Raschke

About author

Joe is a Principal Solution Strategist with Saviynt and has spent the majority of his career across many vertical markets including Manufacturing, Financial, Legal, and Healthcare markets. Joe has managed teams of people at companies ranging from regional firms to global enterprises to develop infrastructure, security and compliance programs. Bringing insight into the mind of a CISO, Joe has implemented regulatory programs to address today’s complex compliance requirements such as HIPAA/HITECH, SOX, and GDPR.

Leave a Reply

Your email address will not be published. Required fields are marked *