diff --git a/peps/pep-0811.rst b/peps/pep-0811.rst
index 88ffee687e3..f832d2e71c0 100644
--- a/peps/pep-0811.rst
+++ b/peps/pep-0811.rst
@@ -59,10 +59,9 @@ Onboarding new contributors to the PSRT
 
 Unlike most open-source contributions, the work of the PSRT doesn't happen
 in the open. Instead, most work occurs privately by a trusted group to limit
-access to undisclosed
-vulnerability reports. Given the sensitive nature of this work, it appears opaque from the outside, and
-it's difficult to get started as a newcomer and to understand the
-expectations of the group.
+access to undisclosed vulnerability reports. Given the sensitive nature of this
+work, it appears opaque from the outside, and it's difficult to get started as a
+newcomer and to understand the expectations of the group.
 
 In practice this has meant that relatively few new members join the PSRT,
 which over time could negatively impact the group's ability to triage reports
@@ -110,8 +109,7 @@ decide who should be admitted, but there must be a system responsible for
 evaluating PSRT membership.
 
 This PEP proposes limiting PSRT membership only to active coordinators
-of security vulnerabilities that are core developers or triagers,
-members involved in oversight (Steering Council),
+of security vulnerabilities, members involved in oversight (Steering Council),
 and members who need information about security releases (Release Managers).
 
 Activity is recommended as the metric for membership to avoid adding additional
@@ -154,12 +152,14 @@ Specification
 PSRT Membership Policy
 ----------------------
 
-The Python Steering Council may add or remove members and admins of the PSRT.
-New PSRT members must be core team members, triagers, or PSF staff,
-and must be `proposed to and accepted`_ by the Steering Council.
+The PSRT will run nominations `similar to core team nominations`_, where
+a nomination of a new member is brought to the PSRT by an existing PSRT member
+and then that nomination is voted on by existing PSRT members. New members
+are expected to be drawn from core developers, triagers, or PSF staff.
+It is granted by receiving at least two-thirds positive votes from a vote of
+existing PSRT members that is open for one week and is not vetoed by the
+Steering Council.
 
-Once the Steering Council votes on a membership change to the PSRT then
-PSRT admins will enact the change.
 A list of PSRT members will be published publicly and kept up-to-date by PSRT
 admins.
 
@@ -167,6 +167,7 @@ Once per year the Steering Council will receive a report of inactive members of
 the PSRT with the recommendation to remove the inactive users from the PSRT.
 "Inactive" is defined here as a member who hasn't coordinated or commented on a
 vulnerability report in the past year since the last report was generated.
+The Steering Council may remove members of the PSRT with a simple vote.
 
 Members of the PSRT who are a Release Manager or Steering Council
 member may remain in the PSRT regardless of inactivity in vulnerability reports.
@@ -176,11 +177,7 @@ in the past year and without an exemption for minimum activity (Steering Council
 Release Managers) prior to publication of this PEP. At the time of writing, this
 would reduce the PSRT membership size to ~15 members from ~30.
 
-This PEP also proposes not removing members of the PSRT who are active but
-not yet core team members or triagers, allowing them to be "legacied" in
-to the new PSRT Membership Policy.
-
-.. _proposed to and accepted: https://github.com/python/steering-council/
+.. _similar to core team nominations: https://devguide.python.org/core-team/join-team/
 
 PSRT Admins
 ~~~~~~~~~~~
@@ -236,7 +233,7 @@ following additional responsibilities:
 
 * Managing the GitHub team, mailing list, Discord channel, and other
   PSRT venues to ensure they are synchronized with the canonical list of
-  PSRT members determined by the Steering Council.
+  PSRT members.
 * On a yearly basis, providing the Steering Council with a report including
   a list of inactive PSRT members.