Compliance

RSS
Sort By:

A Requirements Primer:
A short primer that provides background on four of the most important compliance challenges that organizations face today.

Many software engineers and architects are exposed to compliance through the growing number of rules, regulations, and standards with which their employers must comply. Some of these requirements, such as HIPAA, focus primarily on one industry, whereas others, such as SOX, span many industries. Some apply to only one country, while others cross national boundaries.

by George W. Beeler, Dana Gardner | September 15, 2006

1 comments

Box Their SOXes Off:
Being proactive with SAS 70 Type II audits helps both parties in a vendor relationship.

Data is a precious resource for any large organization. The larger the organization, the more likely it will rely to some degree on third-party vendors and partners to help it manage and monitor its mission-critical data. In the wake of new regulations for public companies, such as Section 404 of SOX, the folks who run IT departments for Fortune 1000 companies have an ever-increasing need to know that when it comes to the 24/7/365 monitoring of their critical data transactions, they have business partners with well-planned and well-documented procedures. In response to a growing need to validate third-party controls and procedures, some companies are insisting that certain vendors undergo SAS 70 Type II audits.

by John Bostick | September 15, 2006

0 comments

Compliance Deconstructed:
When you break it down, compliance is largely about ensuring that business processes are executed as expected.

The topic of compliance becomes increasingly complex each year. Dozens of regulatory requirements can affect a company’s business processes. Moreover, these requirements are often vague and confusing. When those in charge of compliance are asked if their business processes are in compliance, it is understandably difficult for them to respond succinctly and with confidence. This article looks at how companies can deconstruct compliance, dealing with it in a systematic fashion and applying technology to automate compliance-related business processes. It also looks specifically at how Microsoft approaches compliance to SOX.

by J. C. Cannon, Marilee Byers | September 15, 2006

1 comments

Complying with Compliance:
Blowing it off is not an option.

“Hey, compliance is boring. Really, really boring. And besides, I work neither in the financial industry nor in health care. Why should I care about SOX and HIPAA?” Yep, you’re absolutely right. You write payroll applications, or operating systems, or user interfaces, or (heaven forbid) e-mail servers. Why should you worry about compliance issues?

by Eric Allman | September 15, 2006

0 comments

Enclaves in the Clouds:
Legal considerations and broader implications

With organizational data practices coming under increasing scrutiny, demand is growing for mechanisms that can assist organizations in meeting their data-management obligations. TEEs (trusted execution environments) provide hardware-based mechanisms with various security properties for assisting computation and data management. TEEs are concerned with the confidentiality and integrity of data, code, and the corresponding computation. Because the main security properties come from hardware, certain protections and guarantees can be offered even if the host privileged software stack is vulnerable.

by Jatinder Singh, Jennifer Cobbe, Do Le Quoc, Zahra Tarkhani | January 26, 2021

0 comments

Keeping Score in the IT Compliance Game:
ALM can help organizations meet tough IT compliance requirements.

Achieving developer acceptance of standardized procedures for managing applications from development to release is one of the largest hurdles facing organizations today. Establishing a standardized development-to-release workflow, often referred to as the ALM (application lifecycle management) process, is particularly critical for organizations in their efforts to meet tough IT compliance mandates. This is much easier said than done, as different development teams have created their own unique procedures that are undocumented, unclear, and nontraceable.

by Tracy Ragan | September 15, 2006

0 comments

Playing by the Rules:
The complex world of compliance

Some of my favorite childhood memories are of playing games with my sister—both structured games such as Monopoly or hopscotch and imagination-fueled games such as cops and robbers or roller derby girls. Regardless of whether the game had established regulations, often our play would devolve into what I call Calvinball, a term coined in the comic strip Calvin and Hobbes referring to the act of making up the rules as you go along.

by Charlene O'Hanlon | September 15, 2006

0 comments

Seeking Compliance Nirvana:
Don’t let SOX and PCI get the better of you

Compliance. The mere mention of it brings to mind a harrowing list of questions and concerns. For example, who is complying and with what? With so many standards, laws, angles, intersections, overlaps, and consequences, who ultimately gets to determine if you are compliant or not? How do you determine what is in scope and what is not? And why do you instantly think of an audit when you hear the word compliance? To see the tangled hairball that is compliance, just take a look at my company.

by Greg A. Nolann | September 15, 2006

0 comments

Standards Advice:
Easing the pain of implementing standards

My mother took language, both written and spoken, very seriously. The last thing I wanted to hear upon showing her an essay I was writing for school was, "Bring me the red pen." In those days I did not have a computer; all my assignments were written longhand or on a typewriter, so the red pen meant a total rewrite. She was a tough editor, but it was impossible to question the quality of her work or the passion that she brought to the writing process.

by George Neville-Neil | December 30, 2009

4 comments

What Went Wrong?:
Why we need an IT accident investigation board

Governments should create IT accident investigation boards for the exact same reasons they have done so for ships, railroads, planes, and in many cases, automobiles. Denmark got its Railroad Accident Investigation Board because too many people were maimed and killed by steam trains. The UK's Air Accidents Investigation Branch was created for pretty much the same reasons, but, specifically, because when the airlines investigated themselves, nobody was any the wiser. Does that sound slightly familiar in any way?

by Poul-Henning Kamp | July 13, 2021

0 comments