Privacy is all about protecting the rights of the client from unauthorized disclosure or use of their PII. (Personally identifiable information)

Take the example of a process that receives an input from a data feed that contains PII. This information is processed and uploaded to a database or warehouse.

There are possibly 4 points of contact for the PII to flow across.

Data Flow diagrams in architecture are valuable for identifying areas for privacy controls and processes.

A PIA is another good method for flushing out these issues, even if you don’t know the entire picture or finalized solution.

The PIA could be a simple Q&A session like – if the data was accessed by unauthorized means is there a mechanism in your solution that would capture this and alert someone?

Decoupling security from rest of the application would be a good design to start with. You should decouple privacy and security from the main business components of the application and design it as pluggable aspect of your system. This way you will have the opportunity to switch on-off and tune the security settings of your application even at the most granular level of your business functions.

Most modern frameworks provide support for designing and developing such pluggable aspects for enterprise application. Once you have decoupled it from the rest of your application you can elaborate and enhance it further with more business specific security and privacy needs for your application.

  1. The ones who want to incorporate and practice privacy just to commit to external compliance.
    The chosen “others”, who build effective security & privacy controls in order to be able to better audit and govern the enterprise and thereby continually improve the organization security posture.

    A lot of people try a variety of ways to understand what’s happening on the network and correlate with business security use cases. This involves investing in point security solutions but believe me it is always a home grown business critical application that can never get automatically adjusted or configured to those vendor solutions thereby leaving a wide gap of vulnerability.

    Make sure you pay attention to the following when designing your app.

    – Excellent logging capabilities
    – RBAC with real time auditing and notification
    – Threat response mechanism
    – Effective rollback mechanism
    – Application configuration auditing
    – Security health check tests before the app launches.
    – Secure coding practice
    – A hybrid agile development security practice along with the QA cycle.

    These aren’t or may be not very recognized app privacy keywords but this is what I have encountered as issues with my clients where I have worked on multiple accounts.

Consider the following principals from the
OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (23 September 1980)

Collection Limitation Principle
7. There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

Data Quality Principle
8. Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.

Purpose Specification Principle
9. The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfillment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

Use Limitation Principle
10. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except:
a) with the consent of the data subject; or
b) by the authority of law.

Security Safeguards Principle
11. Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data.

Openness Principle
12. There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.

Individual Participation Principle
13. An individual should have the right:
a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him;
b) to have communicated to him, data relating to him
* within a reasonable time;
* at a charge, if any, that is not excessive;
* in a reasonable manner; and
* in a form that is readily intelligible to him;
2. c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and
d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.

Accountability Principle
14. A data controller should be accountable for complying with measures which give effect to the principles stated above.