Most of the companies are recognizing the requirement for application security in all phases of the Software Development Life Cycle (SDLC), while related firms such as the Open Web Application Security Project (OWASP) and the Web Application Security Consortium (WASC) are increasing in popularity. Moreover, regulations such as the Payment Card Industry (PCI) proposal consent that security is well-established in the development and product management lifecycles.

With the propaganda surrounding the secure applications, companies may endeavor broad implementation of secure development principles. Security as an architectural driver is often at the expense of performance (e.g. component idleness), usability (e.g. complexity of using the application) and cost (e.g. using SSL to execute HTTP needs PKI or third party certificates, slows traffic, etc.).  Most development companies are having a tough time balancing all of these factors.

In order to make booming decisions about security tradeoffs, architects and developers require calculating the privacy, reliability, and accessibility needs of their applications. In short, application classification requires heading secure web application development.

In most of the company has shown that, while the majority companies have policies covering data classification, infrequently do they have similar policies on application classification. Developers frequently have to make statements about the sensitivity of the data that they are managing and make architectural and design trade-offs based on these statements. 

On the contrary, an excessively vigilant architect may choose to encrypt all data in an accounting application because of the estimate responsive, when in fact the very same numbers are openly available to the entire enterprise. The architect is protecting discretion where it should actually be focusing on the integrity of the data.