diff --git a/README.md b/README.md
index c7fd8272f..27f4f3089 100644
--- a/README.md
+++ b/README.md
@@ -4,8 +4,8 @@ Working Group Proposal: Secure Access for Everyone (SAFE)
 ## Objective
 
 Secure Access for Everyone (SAFE) Working Group facilitates collaboration
-to discover and produce resources which enable secure access, policy control 
-and safety for operators, administrators, developers, and end-users across 
+to discover and produce resources which enable secure access, policy control
+and safety for operators, administrators, developers, and end-users across
 the cloud native ecosystem.
 
 ## Background
@@ -51,7 +51,7 @@ for both cloud and traditional infrastructure.
 ## Members
 
 * Dan Shaw ([@dshaw](https://github.com/dshaw)), PayPal [chair]
-* Sarah Allen ([@ultrasaurus](https://github.com/ultrasaurus)), Google [chair]
+* Sarah Allen ([@ultrasaurus](https://github.com/ultrasaurus)), [chair]
 * Jeyappragash JJ ([@pragashj](https://github.com/pragashj)), Tetrate.io [chair]
 * Devarajan P Ramaswamy ([@deva](https://github.com/deva26)), PADME
 * Kamil Pawlowski ([@kbpawlowski](https://github.com/kbpawlowski))
@@ -83,6 +83,10 @@ for both cloud and traditional infrastructure.
 * John Morello ([@morellonet](https://github.com/morellonet)), Twistlock
 * Alban Crequy ([@alban](https://github.com/alban)), Kinvolk
 * Michael Schubert ([@schu](https://github.com/schu)), Kinvolk
+* Andrei Manea ([@andrei_821](https://github.com/andrei821)), CloudHero
+* Justin Cappos ([@JustinCappos](https://github.com/JustinCappos)), New York University
+* Santiago Torres-Arias ([@SantiagoTorres](https://github.com/SantiagoTorres)), New York University
+* Brandon Lum ([@lumjjb](https://github.com/lumjjb)), IBM
 * JOIN OUR MEETINGS REGULARLY, THEN ADD YOURSELF VIA PULL REQUEST
 
 ## Related Groups
@@ -92,30 +96,64 @@ for both cloud and traditional infrastructure.
 * [Kubernetes SIG-Auth](https://github.com/kubernetes/community/tree/master/sig-auth)
 * [NIST Big Data WG](https://bigdatawg.nist.gov/)
 
+## Communications
+
+Anyone is welcome to join our open discussions of WG projects and share news related to the group's mission and charter. Much of the work of the group happens outside of WG meetings and we encourage project teams to share progress updates or post questions in these channels:
+
+* [Email list](https://groups.google.com/forum/#!forum/cloud-native-security)
+* [CNCF Slack](https://slack.cncf.io/) #safe-wg channel
+
 ## Meeting Time
 
 The SAFE group meets every Friday at 11:00am PT (USA Pacific):
 
-Join: https://zoom.us/j/709980684
+Join: https://zoom.us/j/665428022
 
 Or iPhone one-tap:
-* US: +16699006833,,709980684# or +16468769923,,709980684#
+* US: +16699006833,,665428022# or +16468769923,,665428022#
 
 Or Telephone:
-* US: +1 669 900 6833 or +1 646 876 9923, Meeting ID: 709-980-684
+* US: +1 669 900 6833 or +1 646 876 9923, Meeting ID: 665-428-022
 * International numbers available: https://zoom.us/zoomconference?m=r-YGNTQJzZphTlO4LYkdhAt4oIQpwl2g
 
 ## In Person Meetings
 
-Please let us know if you are going and if you are interested in attending (or helping to organize!) an in-person meetup (via the linked github issue):
-* KubeCon + CloudNativeCon, Shanghai, Nov 14-15, 2018 - [issue#28](https://github.com/cn-security/safe/issues/28)
-* KubeCon + CloudNativeCon, North America, Dec 11-13, 2018 - [issue#29](https://github.com/cn-security/safe/issues/29)
+Please let us know if you are going and if you are interested in attending (or helping to organize!) an in-person meetup. Create a [github issue](https://github.com/cn-security/safe/issues/new) for an event and add to list
+below:
+
+* KubeCon + CloudNativeCon, Barcelona, Spain, May 20 – 23, 2019 - [issue#127]
+* KubeCon + CloudNativeCon, San Diego, CA - Nov 18 – 21, 2019 - [issue#128]
 
 Past
+* KubeCon + CloudNativeCon, North America, Dec 11-13, 2018 - [issue#29](https://github.com/cn-security/safe/issues/29)
+* KubeCon + CloudNativeCon, Shanghai, Nov 14-15, 2018 - [issue#28](https://github.com/cn-security/safe/issues/28)
 * [KubeConEU](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/) May 2-4, 2018 in Copenhagen, Denmark ([notes](safe_kubecon.md))
 
 ## Meeting Minutes
 
+* [2018-04-12 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - OPA with SAFE Presentation Framework
+* [2018-04-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-04-05 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Google Open Source Project Onboarding
+* [2018-04-04 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-29 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Revised presentation framework with in-toto (OPA, Kamus, TOC invited) 
+* [2018-03-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - SAFE Whitepaper Working Session
+* [2018-03-15 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-07 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-07 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-01 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-02-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-21 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-02-15 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-01 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-01-31 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-01-25 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-01-24 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
 * [2018-01-18 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
 * [2018-01-17 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
 * [2018-01-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
diff --git a/assessments/README.md b/assessments/README.md
new file mode 100644
index 000000000..bf907aa02
--- /dev/null
+++ b/assessments/README.md
@@ -0,0 +1,46 @@
+# Security Assessments
+
+## Goals
+The [security assessment process](guide) is designed to accelerate the adoption
+of cloud native technologies, based on the following goals and assumptions:
+
+### 1) Reduce risk across the ecosystem
+
+The primary goal is to reduce the risk from malicious attacks and accidental breaches of privacy. This process supports that goal in two ways:
+
+   * Clear and consistent process for communication increases detection &
+   reduces time to resolve known or suspected vulnerability issues
+   * A collaborative evaluation process increases domain expertise
+   within each participating project.
+
+### 2) Accelerate adoption of cloud native technologies
+
+Security reviews are a necessary, yet time consuming process, where each
+company, organization and project must perform its own reviews to ensure
+that it meets its unique commitments to its own users and stakeholders.
+In open source, simply finding security-related information can be a very
+time consuming part of the the process. The process is designed to enable improved discovery of security information & streamlined security reviews in multiple ways:
+
+   * Consistent documentation reduces review time
+   * Established baseline of security-relevant information reduces Q&A
+   * Clear rubric for security profile enables organizations to align their
+   risk profile with project’s risk profile and effectively allocate resources
+   (for review and needed project contribution)
+   * Structured metadata allows for navigation, grouping and cross-linking
+
+We expect that this process will raise awareness of how specific open source
+projects affect the security of a cloud native system; however, separate
+activities may be needed to achieve that purpose using materials generated by
+the assessements.
+
+## Outcome
+
+Each project assessment will:
+1. ensure a clear description of the project's design goals with respect to
+security
+2. uncover design flaws and document known limitations
+3. document next steps toward increasing security of the project itself and/or
+increasing the applications of the project toward increasing security of the
+cloud native ecosystem
+
+
diff --git a/assessments/guide/README.md b/assessments/guide/README.md
new file mode 100644
index 000000000..a378948df
--- /dev/null
+++ b/assessments/guide/README.md
@@ -0,0 +1,55 @@
+The SAFE WG has been ask to provide the CNCF’s TOC with effective
+information about the security of different projects.  The purpose of this
+document is to outline the procedure by which a project should be evaluated.
+
+The project assessment process is intended to be a collaborative process for
+the benefit of the project and the community, where the primary content is
+generated by the [project lead](project-lead.md) and revised based on feedback
+from [security reviewers](security-reviewer.md) and other members of the
+working group (WG).
+
+Due to the nature and timeframe for the analysis, *this review is not meant
+to subsume the need for a professional security audit of the code*.  Audits
+of implementation vulnerabilities and similar issues at that level are not
+intended to be covered by this assessment.  The purpose of this effort is to
+uncover design flaws and to obtain a clear articulation of what the project's
+design goals and security properties are intended to be.
+
+
+## Steps
+
+1. Create tracking issue
+   * Issue may be a request from TOC liason or project itself
+2. Project provides self-assessment
+   * [project lead](project-lead.md) responds to the issue with draft document (see [outline](outline.md))
+   * issue assigned to lead [security reviewer](security-reviewer.md) who
+   will recruit a second reviewer, if one not already assigned, and facilitate
+   the process
+3. Inital review
+   * Upon request by the project, security reviewer may do an inital review to
+   verify completeness, ask for clarifications and provide quick feedback
+   * Project posts their document to the group mailing list, allowing at least
+   one week for review before presenting to the WG
+4. Presentation
+   * Project lead presents to WG
+   * This will be recorded as part of standard WG process
+5. Final assessment
+   * Reviewers provide final feedback with recommendations
+   * Either project lead or reviewers may request further WG discussion
+   * Project lead prepares a PR to /assessments/project-docs/project-name/
+
+## Additional Process Notes
+
+Iteration is expected; however, we expect quick turnaround (at most a week).
+In rare cases unrelated issues can unexpectedly interrupt the process and
+it may be appropriate to address specific concerns rather than continuing with
+the assessment. We encourage open communication between project lead and s
+ecurity reviewers:
+
+* At any time, the project lead may request additional time to respond
+  to feedback from security reviewers
+* Project lead or lead security reviewer may pause the process where a delay
+  of over a week cannot be accomodated by the review team. Simply close
+  the github issue with a note to SIG co-chairs.
+
+
diff --git a/assessments/guide/outline.md b/assessments/guide/outline.md
new file mode 100644
index 000000000..c4f2b590f
--- /dev/null
+++ b/assessments/guide/outline.md
@@ -0,0 +1,55 @@
+# Outline
+
+First of all, the burden is primarily on the proposing project to
+demonstrate it is secure in a manner that is understandable to the broader
+community.  The [reviewers](security-reviewer.md) will help to assess and probe the design.
+
+The proposing project must provide a written document that describes the
+project and its security.  The document must contain the following
+information, at a minimum.
+
+* Goal. The intended goal of the projects including the security guarantees
+the project is meant to provide (e.g., Flibble only allows parties with an
+authorization key to change data it stores)
+* Non-goals.  Non-goals that a reasonable reader of the project’s literature
+could believe may be in scope (e.g., Flibble does not intend to stop a
+party with a key from storing an arbitrarily large amount of data, possibly
+incurring financial cost or overwhelming the servers)
+* Scenarios.  The scenarios in which the project is expected to be used.
+This must be specific enough to provide context for analysis.  (e.g.,
+Flibble can be used in any cloud environment.  Three diverse examples are
+as follows.  First, when a Flibble server is used by legacy servers as a
+database for salted password hashes.  Second, a Flibble cloudlet may be run
+on virtualized fog hardware near smartphone users.  Third, a Flibble
+distributed service may serve as a backend for a Notary image registry.)
+* Expected attacker capabilities.  A description of likely capabilities that
+the attacker has in these scenarios should be described.  Both assumptions
+about the strength and limitations of attackers should be described.
+(e.g., We assume that an attacker may be able to exploit implementation
+errors in some set of the servers to take control of them.  However, we
+assume the attacker cannot break AES or SHA256.)
+* Design.  A description of the system design that discusses how it works.
+This is especially critical for any mechanisms that relate to the security
+of the system.
+* Operation.  A description of the operational aspects of the system, such as
+how keys are likely to be managed and stored.
+* Attacker motivations.  A discussion about the likely goals of an attacker.
+This likely relates closely to the impact of different attacks in the
+scenarios.  (e.g., In the password hash case, the attacker wants to expose
+those hashes on the Flibble server.  However, a Flibble cloudlet attacker
+may find it more interesting to bring down the service.)
+* Security degradation.  A discussion about the resulting security when
+various attacks are launched.  Note, that no system is secure in all
+scenarios, hence it is expected that this will include areas where attacks
+compromise all meaningful security.  (e.g., If an attacker is able to
+compromise the “master” Flibble server, they may read, write, or delete any
+content stored on any system)
+* Attack risk.  A rough estimation of the risk posed by different attacks.
+(e.g., The master Flibble server only communicates with Flibble servers
+using a minimalistic API that is formally verified and written in Rust.)
+* Software.  A link to the software’s repository.
+* Development pipeline.  A description of the testing and review processes
+that the software undergoes as it is developed and built.
+* CII Best Practices.  A brief discussion of where the project is at with
+respect to CII best practices and what it would need to achieve the badge.
+
diff --git a/assessments/guide/project-lead.md b/assessments/guide/project-lead.md
new file mode 100644
index 000000000..74979199c
--- /dev/null
+++ b/assessments/guide/project-lead.md
@@ -0,0 +1,13 @@
+# Project Lead
+
+In the context of the security assessment, the "project lead" should be
+someone on the security team for the project. For new or smaller projects
+without an established security team, this could be a project maintainer
+or they may delegate to a regular contributor who has an interest in security.
+
+## Expected time / effort
+
+The level of effort for the team providing the information is expected to
+be around 80 hours of work.  Note, that projects that have already
+performed a security analysis internally are expected to have much lower
+requirements.
diff --git a/assessments/guide/security-reviewer.md b/assessments/guide/security-reviewer.md
new file mode 100644
index 000000000..a4eeab3bd
--- /dev/null
+++ b/assessments/guide/security-reviewer.md
@@ -0,0 +1,31 @@
+# Security Reviewers
+
+Reviewers will try to understand the
+system and probe its security.  Specifically design level issues are meant
+to be addressed as well as high level problems with the project’s setup and
+operation. This is meant to provide an independent analysis and estimation
+of the above information.  The goal is to ask questions to understand if
+there are hidden assumptions, underestimated risk, or design issues that
+harm the security of the project.  It may be useful to reach out to
+community members to understand the answers to some questions, especially
+involving deployment scenarios and the impact of attacks.
+
+## Qualifications
+
+Unless approved by the SIG chairs, at least one of the reviewers will
+have previously performed a SAFE WG audit.  (Exemptions are expected to be
+granted bootstrap the process but only in extreme cases later on.)  In
+general, a reviewer should have performed security audits for diverse
+organizations.  The ideal reviewer should also have been the recipient
+of security audits for a software project they manage.  Note that it is
+encouraged to have participation (shadowing) from participants that are not
+yet qualified to help them gain the necessary skills to be a reviewer
+in the future.
+
+## Time and effort
+
+The level of effort for the reviewers is expected to be 10 hours.
+Despite the fact that there may be some back and forth to get clarification
+on a few points, it is expected analysis can usually be concluded in a few
+weeks.  This will primarily involve carefully reading the written
+document and analyzing the security assertions and assumptions.
diff --git a/landscape/categories.md b/landscape/categories.md
index 9924933a7..9f0b9248d 100644
--- a/landscape/categories.md
+++ b/landscape/categories.md
@@ -15,7 +15,7 @@ sub-categories. The remaining text is a description of each sub-category.
     - Tools that facilitate automated security testing in pipelines;
     eg for functional security tests of authn and authz,
       tests of known potential weaknesses or misconfigurations
-  - _Piplines_
+  - _Pipelines_
     - Tools that ensure a secure pipeline or workflow, for example,
     as applied to devops (CI/CD), supply chain, etc.
 
diff --git a/safe_usecases.md b/usecases.md
similarity index 77%
rename from safe_usecases.md
rename to usecases.md
index e6983cdbb..74a616e9c 100644
--- a/safe_usecases.md
+++ b/usecases.md
@@ -1,34 +1,47 @@
-Authors: stummidi@pivotal.io, rayc@google.com, pragashjj@gmail.com, ckemper@google.com 
+Authors: stummidi@pivotal.io, rayc@google.com, pragashjj@gmail.com, ckemper@google.com
 
-Created: 7 March 2017
+Updated: 9 April 2019
 
-This is a living document, please feel free to add use cases and personas through a PR. We want this to be a repository of cloud native security related use cases.
+This is a living document, please feel free to add use cases and personas through a PR. 
+This initial version was derived from inputs referencd below.  Please add 
+references for new use cases, which could included shared documents from other 
+projects, published research or case studies of cloud native technologies in
+real world use.
+ 
+## References
 
-Refer:
-============
+* SAFE Cloud Foundry Use Cases: https://goo.gl/4pmdqt
+* Administrators Bill of Rights: https://goo.gl/yQCxE8
 
-SAFE Cloud Foundry Use Cases: https://goo.gl/4pmdqt
+Overview
+============
+This is a list of use cases to enable secure access, policy control and safety
+for users of cloud native technology.
 
-Administrators Bill of Rights: https://goo.gl/yQCxE8
+## Users
 
+Within an enterprise, based on the organization structure, we may have one or 
+more of the personas. The more general user categories are
+separated into these more detailed personas where roles may be held by 
+different people in a large organization.
 
-Summary 
-============
-Within an enterprise, based on the organization structure, we may have one or more of the personas. They could be from Developer, Enterprise Operator, Network Operator, End User, Infrastructure Provider. In this document, we will try to breakdown the use cases by applying bill of rights to each personas. 
+* Operators: Enterprise, Quota, Network
+* Administrators: Security, Compliance/Audit
+* Developers, including Third Party Security Products
+* End-users 
 
-Developer
-=============
-* As a developer, I need to provide logs for any changes to a critical resources, such that they can be made available for auditing
+A project will often have a very focused target audience and not all
+use cases are applicable in every situaton.  The use cases below are a guide
+to consider common needs that often require support from multiple products
+or technologies in order to be fully functional for the target users.
 
-* As a developer, I need to be able to tag my resources so that they can be grouped by an administrator when required
+# Operators
 
-* As a developer I need to be able to perform an access check for a resource
+## Enterprise 
 
-Enterprise Operator
-=============
 * As an enterprise operator, I need a central way to look at the organizational resources, so that I can administer them in a single view
 
-* As an enterprise operator, I need the ability to see what about the resource changed, who changed it and when it was changed, so that I can report on for compliance 
+* As an enterprise operator, I need the ability to see what about the resource changed, who changed it and when it was changed, so that I can report on for compliance
 
 * As an enterprise operator, I need a way to delegate policy control to lower level admins, including sub enterprise operators, who help me scale.
 
@@ -43,8 +56,19 @@ Enterprise Operator
 * As an enterprise operator, I can understand the effect of changes to policy that I am making
 
 
-Quota Operator
-==================
+## Quota 
+
+Since quota is often used for cost control, this may imply a different persona
+with financial, rather than an engineering background.
+
+An important use of quota is to protect a service from abuse. By setting a
+quota, we can ensure that a single individual or group cannot bring down the
+service for everybody else (either intentionally or unintentionally).
+For example, services may lack sufficient protections (such as exponential
+backoff) and a simple quota enforcement in front of the service can reduce the
+impact of repeated request on the rest of the infrastructure.
+
+
 
 * As an quota operator, I need a central way to look at the organizational resources, so that I can administer them in a single view
 
@@ -61,8 +85,7 @@ Quota Operator
 * As a quota operator, I can understand the effect of changes to quota that I am making
 
 
-Network Operator
-====================
+## Network 
 
 * As a network operator, I need a central way to look at the networks in my organization, so that I can administer them in a single view.
 
@@ -75,20 +98,9 @@ Network Operator
 * As a network operator, I can understand the effect of changes to network policy that I am making
 
 
-End User
-============
+# Administrators
 
-* As an end user, I can understand which resources I can access and how I can request access to a resource
-
-* As an end user, I can delegate or revoke access to downstream applications/resource or other users
-
-* As an end user, I can request access to a resource and operations.
-
-* As an end user, I can understand the effect of changes to policy that I am making
-
-
-Compliance Officer /Auditor
-===============================
+## Compliance Officer / Auditor
 
 * As a compliance officer, I can <a href="https://docs.google.com/document/d/19V_Vx0fdz2HOa31FpPswT9CsUphizfJcwvDJv05aWFs/edit#heading=h.norkt12d88ma" target="_blank">audit</a>  all accesses and understand all policy grants for my organizations’ cloud resources - including all accesses of other administrators.
 
@@ -103,8 +115,7 @@ Compliance Officer /Auditor
 * As a compliance officer, I can configure my organization's resources to meet the requirements of relevant standards such as [PCI](https://www.pcisecuritystandards.org/), [FedRAMP](https://www.fedramp.gov/) or [HIPAA](https://www.gpo.gov/fdsys/pkg/PLAW-104publ191/html/PLAW-104publ191.htm), and I can generate assessment and attestation artifacts showing how the relevant requirements are met.
 
 
-Security Administrator
-==========================
+## Security Administrator
 
 * As a security administrator, I can <a href="https://docs.google.com/document/d/19V_Vx0fdz2HOa31FpPswT9CsUphizfJcwvDJv05aWFs/edit#heading=h.ems5pk2exnlb" target="_blank">centrally administer</a>  my organizations’ cloud resources.
 
@@ -122,15 +133,36 @@ Security Administrator
 
 * As a security administrator, I can <a href="https://docs.google.com/document/d/19V_Vx0fdz2HOa31FpPswT9CsUphizfJcwvDJv05aWFs/edit#heading=h.7wavwjkp2pz2" target="_blank">exercise the above rights in hybrid and mutli-cloud deployments</a>  without compromising my ability to manage my organizations’ cloud resources.
 
+# Developers
 
-Third Party Security Product/System
-==========================
+* As a developer, I need to provide logs for any changes to a critical resources, such that they can be made available for auditing
+
+* As a developer, I need to be able to tag my resources so that they can be grouped by an administrator when required
+
+* As a developer I need to be able to perform an access check for a resource
+
+# Third Party Security Product/System
 
 * A third party system should be able to affect security policy based on assets being tagged as quarantined.
 
     * To put it more generically, I should be able to associate resources with dynamic labels/tags which can be used to trigger certain policies
 
 
-    
+
+
+# End-users
+
+* As an end user, I can understand which resources I can access and how I can request access to a resource
+
+* As an end user, I can delegate or revoke access to downstream applications/resource or other users
+
+* As an end user, I can request access to a resource and operations.
+
+* As an end user, I can understand the effect of changes to policy that I am making
+
+
+
+
+