OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pbd-se message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [pbd-se] Privacy Risk Management for Federal Information Systems Observations by Gail Magnuson

Great feedback! All so far!


I have not completed mine, but they will center on:


??? WHAT is their real goal / objective  -- at some point we need help to BUILD in privacy..     

As that privacy approach should generally try to map to the usual “IA” coverage as well, security - the usual “C-I-A” triangle…  aka, the three aspects / focus areas they point out.


1 – Concur that we must map privacy protection (and all we do in cyber) back to risk management key elements – while they state that, it should be clearer on how the process starts with business goals to risks (like PMRM did!!!) – thus it helps to build in privacy (using controls, etc) .   It seems they are starting over and not using the great efforts that exist now..

Agree that this is just a first version… start high-level then work our way down..


2 – We all / they also need to be ‘all in’ on NIST’s very own ‘cyber security framework’  mapping the privacy elements into their five phases.. identify, protect, detect, respond and recover as much as we can..

3 – Requirements themselves need to harmonize globally and lead to specifications so folks can build privacy enhanced technologies (PETs)

-          For example, the three main dimensions they define are different from the ones European privacy groups have defined

-          without mapping back to an overall, generally accepted, global  ‘privacy policy’ as a foundation FIRST (PbD, FIPS, OECD, etc..) , how do we gauge the effectiveness of any requirements first, THEN how do we develop common specifications to build to?

-          It seems a better approach is to set the stage on the NEED first, what is NIST’s privacy vision?  Then USE / aggregate the many privacy requirements that exist into something as a ‘common core’ directly aligned to PbD, et al..



4 – The privacy community needs privacy specifications to build in privacy….

The current policy, requirements, flow down current process is too wide and variable to effectively accommodate and guide providing privacy specifications – we need to build those from the bottom up and then ensure all privacy requirements, however they are developed, can be accommodated as best we can adjusting the specs as we go forward.



From: pbd-se@lists.oasis-open.org [mailto:pbd-se@lists.oasis-open.org] On Behalf Of Antonio kung
Sent: Tuesday, June 16, 2015 7:09 AM
To: pmrm@lists.oasis-open.org; pbd-se@lists.oasis-open.org
Subject: Re: [pbd-se] Privacy Risk Management for Federal Information Systems Observations by Gail Magnuson


Dear all,

Some remarks from me

Antonio Kung

Le 16/06/2015 15:32, Gail Magnuson a écrit :



Attached are my observations and comments.


Best, Gail

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]