Of all the words that make IT people cringe, "audit" has to be in the top ten. However, many companies today, especially those in the financial services and medical sectors, view successful compliance audits as THE critical success factor for their CIO. This is largely due to a few high profile cases of personal data loss due to hacking, and it may be nothing more than the concern du jour for IT managers. Nevertheless, IT architects need to be aware of the major compliance concerns for new applications, and should address those concerns in their designs.
At a high level, compliance auditors are going to be looking at six areas of your application architecture:
1) Access Control, which is a security concern that is normally considered in the architecture anyway.
2) Data Integrity, specifically the confidentiality of personal data belonging to customers and employees of a company.
3) Disaster Recovery
4) Third Party Services, which can be traced directly to sound contracts and SAS70 compliance for all outside partners that connect to a system.
5) Capacity Planning and Performance Monitoring, which are pretty well known entities for most large IT shops.
6) Change Management, especially as it relates to the SDLC and the specific organizational controls, checks and balances around production deployment.
Architecting for compliance involves not only addressing each of these areas in the design, but also ensuring that the area is easily audited. This means that the compliance of the architecture with the published standards (such as SOX and the CDP Act) can be easily demonstrated to the auditor through material evidence that is reproduceable at will. This is easily said, but not necessarily so easily done.
In upcoming posts, I will discuss each of these areas from the architectural perspective and provide some tips on how to build these concerns into IT projects from the cradle. Doing so will give your client confidence in your concern for the well being of their company, which is good for everyone concerned.