Michael,
Thank you . I’m working on integrating your edits (and Stuart’s) into the draft format that Peter Brown created. One comment is I think we need to look closely at the definition of “control,” since it has a
broader meaning within the audit community. For example this is from the Committee of Sponsoring Organizations of the Treadway Commission (COSO) as one example, but there are other similar ones. I think we need this larger definition so that our definition
is not entirely focused on risk management controls, but also operational/management controls . (see
http://coso.org/IC-IntegratedFramework-summary.htm/ )
|
Internal control is broadly defined as a process, effected by an entity's board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives
in the following categories: 1. Effectiveness and efficiency of operations.
2. Reliability of financial reporting.
3. Compliance with applicable laws and regulations.
|
John Sabo
CA Technologies
Director, Global Government Relations
Tel: +1 202-513-6304
Mobile: +1 443-629-6198
john.t.sabo@ca.com
From: pmrm@lists.oasis-open.org [mailto:pmrm@lists.oasis-open.org]
On Behalf Of Michael Willett
Sent: Friday, January 13, 2012 11:58 AM
To: pmrm@lists.oasis-open.org
Subject: [pmrm] PMRM v09 comments... re: controls/FIPPs/Services
Importance: High
As noted in the PMRM TC telecom, I am drafting wording
that makes more explicit in the V09 draft the resolution steps going from
privacy controls to FIPPs to PMRM Services
These are key steps in going from the initial use case analysis
to an operational system design; eventually, to a privacy management implementation.
>>> BACKGROUND <<<
The excellent flow chart shows these steps:
- High level/detailed/PI analysis
o PI exchanged between (sub)SYSTEMS within DOMAINS
- Operational Privacy CONTROLS
o CONTROLS = measures to avoid, counteract, or minimize risk
- SERVICES needed re: Controls
- Technical/Process MECHANISMS
- Risk Assessment (of selected Services)
- Iterative Process
- operational FIPPs (fair information principles/practices)
… “operational definitions” are intended to be used in the PMRM to support development of the Detailed Privacy Use Case Analysis”
described in Section 4. Their use is completely optional, but may be helpful in organizing privacy requirements and controls where there are inconsistencies in definitions across policy boundaries or where existing definitions do not adequately express the
operational characteristics associated with Fair Information Practices/Principles.
Current v09 draft sections matching the flow chart:
Section 4.3: CONTROLS
Section 4.4: Service DEFINITIONS
Section 4.5: Functions/business processes re: Services
Section 4.6: Risk Assessment…. of the Services within the use case.
Section 4.7: Iteration
Section 5: FIPPs
>>> MY SUGGESTIONS <<<
A - The resolution/reduction sequence is: privacy controls to FIPPs to PMRM Services (to Functions/mechanisms to Risk Assessment to Iterate for detailed refinement)
B - add the definition of CONTROLS (=measures to avoid, counteract, or minimize risk) to section 4.3
C – move the discussion of FIPPs (section 5) into Section 4.3; move the actual ‘sample’ FIPPs definitions to an Appendix.
To the verbiage in the (moved) section 5, add:
- Select appropriate FIPPs that satisfy and map to the identified Control requirements
D – End Section 4.4 with:
For each data flow exchange of PI – incoming, internally generated, outgoing - between (sub)Systems within privacy Domains,
identify the Services that conform to and satisfy the identified
privacy controls and FIPPs required for that data flow.
This detailed conversion into Service operations can then be synthesized into consolidated sets of
Service actions per System involved in the Use Case.
E – add to Section 4.5:
The Services defined in Section 4 encompass detailed Functions and Mechanisms needed to transform
the privacy controls and FIPPs of section 4.3 into an operational system design for the Use Case.
F – add to section 4.7:
The steps in developing the use case that are described above can be iterated, with
further granularity and detail added at each iteration. The Functions and business processes
identified at a high level in Section 4.5 can be refined and further converted to explicit
Mechanisms and business processes. In this way, the use case can evolve from the requirements stage involving Controls and FIPPs, to
the Service-based solution, to a detailed system design involving Functions and mechanisms, eventually
to a comprehensive privacy management implementation. Each stage in this iterative refinement
will provide further insight into the privacy implications of the use case.
G – For the use case illustration:
- we decided to spread the use case development across the sections
- So, the ‘spread’ would introduce consecutive parts in the list, per sections of the doc:
o high level
o detailed
o PI
- These first three parts are as shown in V09
o Controls/FIPPs
o Services
- These parts (above) are on a per I/O flow per System (per Domain)
- remember our development of the Emergency Responder use case
o some partial inclusion of Functions/mechanisms
o risk assessment discussion (brief)
o short “essay” on iteration and refinement
For illustration and simplicity, use TABLES in the evolving use case.
But, in practice and for substantial use cases, modeling tools are
appropriate that support automation (linkages) and facilitate refinement.
H – The flow chart can be lightly modified to match above
Of course, this drafty verbiage can be polished a lot. I am simply
trying to illustrate the point.
Michael