Demystifying Regulatory Guidelines

FEA01x - edited feature imageThere are several regulations out there that tell you how you should be handling your data.  Some organizations are held accountable to multiple different regulations at the same time. Some of these regulations may be in conflict with another.

However, at the base of all of the regulations, they look towards many of the same things in order to ensure that your data remains protected and processed correctly.

In the regulations, the data standards define “what” you should be doing with your data.  They outline what information needs to be protected/audited.

They also talk about what you should do in case of a data breach.  Many of the regulations also define security standards or “how” to process your data. They might cover how you should configure your network or your systems.

In this feature, we’ll take a look at what these regulations state about handling your data:

  • CIS (Center for Internet Security) – Global Internet Security Standards
  • DISA/STIG (Defense Information Systems Agency) – Anyone with Government Contracts
  • FISMA/NIST (Federal Information Security Management Act) – All Federal Agencies
  • FERPA (Family Education Rights and Privacy Act) – Educational Institutions
  • GDPR (General Data Protection Regulation) – Anyone collecting data on EU Members
  • HIPAA (Health Insurance Portability and Accountability Act) – Healthcare Institutions
  • NERC-CIP (North American Electricity Reliability Corporation) – Electricity Providers
  • PCI DSS (Payment Card Industry Data Security Standard) – Anyone capturing credit card data
  • SOX (Sarbanes Oxley) – Publicly Traded Companies and management and accounting firms

In a nutshell, the regulatory guidelines look for 5 key elements in how you should handle your data:

  • Reporting (and maintaining) audit data
  • Tracking user access
  • Protecting the data from the bad guys (and watching for data breaches)
  • Planning and having good processes and response plans
  • Assessing your risks

In many cases, the regulations will identify very clearly what they expect in regard to these elements.


  • Tracking
  • Capture your Logins and Failed Logins


  • Reporting
  • Generate audit records for DoD defined auditable events
  • Generate audit records when privileges and permissions are retrieved
  • Initiate session auditing upon startup
  • Audit records for events identified by type, location, and subject
    • Capture the audit information in a centralized place
  • Tracking
    • Capture record and log all content related to a user session
    • Protect audit information from unauthorized read access, modification, or deletion
  • Planning
    • Alert support staff in real time for any failure events 


  • Tracking
    • Audit access
  • Protecting
    • Monitor, report, and respond to incidents
  • Planning
    • Create an audit process and certification
    • Plan for contingency
    • Manage your configurations
  • Assessing
    • Assess your risks
    • Confirm system and information integrity 


  • Tracking
    • Document who has access to student information
    • Confirm that the instructors or officials only access records for legitimate purposes
    • Authorized representatives may have access to education records in connection with an audit
  • Planning
    • Student transfers must be handled appropriately


  • Reporting
    • Provide audit details about how that data is processed and who interacted with it
  • Tracking
    • Know who has access to PII data
  • Protecting
    • Notify the supervising authority of a breach within 72 hours
  • Planning
    • Identify PII Data
    • Process data lawfully, fairly, and in a way that users understand
    • Limit the collection of data to only what is necessary
  • Assessing
    • Conduct impact assessments for higher risk areas


  • Tracking
    • Monitor log-in attempts
  • Protecting
    • Protect, detect, contain, and correct security violations
    • Detect breaches and notify impacted individuals
  • Planning
    • Implement security measures to reduce risks and vulnerabilities
    • Implement procedures to regularly review audit logs, access reports, and security incidents
    • Implement procedures to terminate access 


  • Reporting
    • Log events for identification of and after-the-fact investigations of Cyber Security Incidents
  • Tracking
    • Log failed and successful logins


  • Reporting
    • Implement automated audit trails for all database events
    • Retain audit trail history for at least a year
  • Tracking
    • Assign a unique identifier for each person who has access
    • Actions taken on critical data must be traced to known authorized users
    • Track and monitor all access to the network
    • Immediately revoke access for terminated users
  • Protecting
    • Change vendor supplied defaults and disable unnecessary default accounts
    • Encrypt the data
    • Secure audit trails so they cannot be altered
  • Planning
    • Develop configuration standards


  • Reporting
    • Report on effectiveness of company’s internal controls and procedures
    • Report on who changed permissions
    • Report on who changed the financial data
  • Tracking
    • Report on who accessed the financial data
    • To help you out, SQL Server does have some native capabilities that can address some compliance needs.

SQL Server

  • Reporting
    • SQL Server Audit
    • Temporal Tables
  • Tracking
    • Object Level Permissions
    • Role-Based Security
  • Protecting
    • Authentication Protocols
    • Firewalls
    • Dynamic Data Masking
    • Transport Level Security (TLS)
    • Encryption Protocols (TDE, Always Encrypted, Always On) 

SQL Compliance Manager

  • Reporting
    • Capture Activity On Database (DDL And DML)
    • Track The Behavior Of Privileged Users
    • Track Who Is Accessing Your Sensitive Data
    • Track Who Has Changed Your Data And What Has It Changed To
    • Track Security And Administrative Changes
    • Track User-Defined Events
    • Audit Systems Tables, Stored Procedures, Views, Indexes, Etc.
  • Tracking
    • Capture Logins, Logouts, Failed Logins
  • Protecting
    • Determine How Much Data Was Accessed In A Breach

Idera Software has given permission to use this content.

Share this post

Kim Brushaber

Kim Brushaber

Kim Brushaber is the Senior Product Manager for ER/Studio Business Architect at IDERA. Kim has over 20 years of experience as a Business Analyst, Software Developer, Product Manager and IT Executive. Kim enjoys working as the translator between the business and the technical teams in an organization.

scroll to top