Skip to main content

Information Security: SOX, SOC2, ISO 27001, PCI-DSS, OMG!


Let’s talk about certifications, standards, controls, control frameworks, etc.

Let’s start with standards.


Per Wikipedia:

The Sarbanes–Oxley Act of 2002...more commonly called Sarbanes–Oxley or SOX, is a United States federal law that set new or expanded requirements for all U.S. public company boards, management and public accounting firms. A number of provisions of the Act also apply to privately held companies, such as the willful destruction of evidence to impede a federal investigation.

The bill...was enacted as a reaction to a number of major corporate and accounting scandals, including Enron and WorldCom. The sections of the bill cover responsibilities of a public corporation's board of directors, add criminal penalties for certain misconduct, and require the Securities and Exchange Commission to create regulations to define how public corporations are to comply with the law.

In a nutshell (and bearing in mind that I am not an expert), SOX is a set of guidelines that came in response to the fraud committed by Enron, etc. Imagine if an “evil” CEO told someone in the company to “cook the books”. The goal of SOX compliance is to make it hard to actually pull that off in practice. You do that by making sure things are reviewed (limit what one person can do on their own), auditable (the logs are good), reasonable (you should take reasonable steps to be secure), and appropriate (a person in accounting shouldn’t be able to tweak the code).

What’s in scope is anything that mutates financial impacting data (data that would lead to revenue reports). For instance, you might be concerned about employees having read-only access to personal information, but from a SOX perspective, since it’s read-only, it doesn’t allow people to alter financial information, and thus it’s out of scope.

Finally, there’s an understanding that you can’t be 100% perfect against every possible attack--zero percent risk is not a thing. Given someone senior enough and someone hacky enough, if they’re willing to steal people’s passwords and delete your entire AWS infrastructure (thereby killing all the logs), there’s no protecting against that. Consider how likely a risk is. The goal is to be “reasonable and appropriate”. Look at the risk. Mitigate it to the degree you can. Be intentional about risk management.

SOX isn’t that scary. Just think through your normal business. If there’s a risk that people can do inappropriate things, put in procedures to prevent them from doing those things.

It is required by law that a company be compliant with SOX “roughly” a year after going public.


Per Wikipedia:

System and Organization Controls (SOC), defined by the American Institute of Certified Public Accountants (AICPA), is the name of a suite of reports produced during an audit. It is intended for use by service organizations (organizations that provide information systems as a service to other organizations) to issue validated reports of internal controls over those information systems to the users of those services...[There are] two levels of reporting, type 1 and type 2. Additional AICPA guidance materials specify three types of reporting: SOC 1, SOC 2, and SOC 3.

These controls have to do with:

  1. Security

    • Firewalls

    • Intrusion detection

    • Multi-factor authentication

  2. Availability

    • Performance monitoring

    • Disaster recovery

    • Incident handling

  3. Confidentiality

    • Encryption

    • Access controls

    • Firewalls

  4. Processing Integrity

    • Quality assurance

    • Process monitoring

  5. Privacy

    • Access control

    • Multi-factor authentication

    • Encryption

A SOC2 report says that as a service provider, you have a reasonable approach to information security. It says that you do what you claim you do, and that you have a documented process. Clients worldwide might ask you for this as a requirement before doing business with you, and it’s also useful during the process of doing public.

ISO 27001

Per Wikipedia:

ISO/IEC 27001 is an international standard on how to manage information security. The standard was originally 2005 and then revised in 2013. It details requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS) – the aim of which is to help organizations make the information assets they hold more secure. A European update of the standard was published in 2017. Organizations that meet the standard's requirements can choose to be certified by an accredited certification body following successful completion of an audit.

ISO 27001 is similar to SOC2, but it’s way more stringent and comprehensive. As with SOC2, clients worldwide might ask you for this as a requirement before doing business with you, and it’s also useful during the process of going public.


Per Wikipedia:

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes...The standard was created to increase controls around cardholder data to reduce credit card fraud.

Validation of compliance is performed annually or quarterly by a method suited to the volume of transactions handled.

Payment processors require you to be compliant with PCI DSS. The more transactions you do, the stricter they are. At a certain point, you are required to have an audit performed by QSA rather than performing a self-assessment.

Controls and Control Frameworks

Per Wikipedia:

Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. In the field of information security, such controls protect the confidentiality, integrity and availability of information.

Systems of controls can be referred to as frameworks or standards. Frameworks can enable an organization to manage security controls across different types of assets with consistency...

Security controls can also be classified according to their nature, for example:

  • Physical controls e.g. fences, doors, locks and fire extinguishers;
  • Procedural or administrative controls e.g. incident response processes, management oversight, security awareness and training;
  • Technical or logical controls e.g. user authentication (login) and logical access controls, antivirus software, firewalls;
  • Legal and regulatory or compliance controls e.g. privacy laws, policies and clauses.

Going back to ISO 27001, it’s actually a control framework. Per Wikipedia:

Most organizations have a number of information security controls. However, without an information security management system (ISMS), controls tend to be somewhat disorganized and disjointed, having been implemented often as point solutions to specific situations or simply as a matter of convention...ISO/IEC 27001 requires that management:

  • Systematically examine the organization's information security risks, taking account of the threats, vulnerabilities, and impacts;
  • Design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable; and
  • Adopt an overarching management process to ensure that the information security controls continue to meet the organization's information security needs on an ongoing basis.

The current ISO 27001 standard lets you pick the controls that you deem most appropriate, but a previous version of the standard had an annex that had the following (per Wikipedia):

There are 114 controls in 14 groups and 35 control categories:

  • A.5: Information security policies (2 controls)
  • A.6: Organization of information security (7 controls)
  • A.7: Human resource security - 6 controls that are applied before, during, or after employment
  • A.8: Asset management (10 controls)
  • A.9: Access control (14 controls)
  • A.10: Cryptography (2 controls)
  • A.11: Physical and environmental security (15 controls)
  • A.12: Operations security (14 controls)
  • A.13: Communications security (7 controls)
  • A.14: System acquisition, development and maintenance (13 controls)
  • A.15: Supplier relationships (5 controls)
  • A.16: Information security incident management (7 controls)
  • A.17: Information security aspects of business continuity management (4 controls)
  • A.18: Compliance; with internal requirements, such as policies, and with external requirements, such as laws (8 controls)

Other Control Frameworks

There are many control frameworks, and they overlap. As you can imagine, a company might need to meet several standards at the same time. To do so, a company might compile a list of all of the controls from all of the frameworks and organize them into a new, all-encompassing control framework.

For instance, Adobe has such a framework:

The Common Control Framework (CCF) by Adobe is the foundational framework and backbone to our company-wide security compliance strategy. The CCF is a comprehensive set of simple control requirements, aggregated, correlated, and rationalized from industry information security and privacy standards.

Your own company might have its own control framework. This could exist, for instance, as a spreadsheet listing all of your controls, how you implement those controls, and what part of each standard the control applies to.

To explain it from a programmer’s point of view, think of each standard as a Java interface. Think of each control as a required method within that interface. Think of your company as a class that implements all of these interfaces by implementing the various required methods.


There are various compliance standards that are required in different situations. SOX is for public companies in the US. PCI DSS is for companies that accept credit card transactions. SOC2 and ISO 27001 are both about running a business in a sensible, robust manner with a special focus on information security.

Controls are specific things like a firewall or a terms of service agreement. If you take a set of controls and organize it into a unified whole, you have a control framework. Your own company might have its own control framework which matches the standards that you need to follow.

Sometimes you need to be certified by an external auditor that you meet a standard. If they flag you with an exception (i.e. a case where you fail to live up to the standard), you need to address that.

Some of your clients might ask that you either comply with SOC2 or ISO 27001. If you're making use of a service or other vendor that stores or processes your critical data (such as email addresses or payment card data) or if they integrate with your infrastructure, you might check their SOC2 and/or ISO 27001 compliance.


Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p