diff --git a/SecurityPolicy.html b/SecurityPolicy.html
index c96d319..3136ae1 100644
--- a/SecurityPolicy.html
+++ b/SecurityPolicy.html
@@ -52,7 +52,7 @@ Status: <i>work-in-progress</i>
 <p>
 This Security Policy sets out the policy
 for the secure operation of the CAcert critical computer systems.
-These computer systems include:
+These systems include:
 </p>
 <ol><li>
      Physical hardware mounting the logical services
@@ -69,23 +69,17 @@ These computer systems include:
 <h4><a name="1.1.1">1.1.1.</a> Effected Personnel </h4>
 
 <p>
-These roles and teams are effected:
+These roles are directly covered:
 </p>
 
 <ul><li>
-      Hardware Controllers (Oophaga)
+      Access Engineers
     </li><li>
-      Direct Hardware Access Systems Administrators
-      (as listed in Oophaga Appendix B Access List)
+      Systems Administrators
     </li><li>
-      Application Administrators
-      (online access to critical systems at Unix level)
+      Supporters
     </li><li>
-      Support Team
-      (online access via administration interfaces)
-    </li><li>
-      Software Development Team
-      (approval of application code) 
+      Software Assessors
 </li></ul>
 
 <h4><a name="1.1.1">1.1.2.</a> Out of Scope </h4>
@@ -105,13 +99,13 @@ Important principles of this Security Policy are:
 <ul><li>
       <i>dual control</i> -- at least two individuals must control a task
     </li><li>
-      <i>four eyes</i> -- at least two individuals must be present during a task,
+      <i>four eyes</i> -- at least two individuals must participate in a task,
       one to execute and one to observe.
     </li><li>
       <i>redundancy</i> -- no single individual is the only one authorized
       to perform a task.
     </li><li>
-      <i>escrow</i> -- where critical information (backups, passwords)
+      <i>escrow</i> -- where critical information (backups, passphrases)
       is kept with other parties
     </li><li>
       <i>logging</i> -- where events are recorded in a file
@@ -137,7 +131,7 @@ deriving from the above principles.
     See &sect;1.1.
 </dd>
 
-<dt><i>Software Developer </i> </dt>
+<dt><i>Software Assessor </i> </dt>
 <dd>
     A Member who reviews patches for security and workability,
     signs-off on them, and incorporates them into the repository.
@@ -169,6 +163,8 @@ for audit purposes (DRC).
 It is under the control of Policy on Policy for version purposes.
 </p>
 
+<p align="center">These parts are not part of the policy:  <span class="q">green comments</span>, <span class="error">red errors</span>.</p>
+
 <p>
 This policy document says what is done, rather than how to do it.
 </p>
@@ -188,7 +184,7 @@ It is located and version-controlled on the CAcert wiki.
 
 <p>
 Section Headings are the same in both documents.
-Where Section Headings are empty in one document,
+Where Sections are empty in one document,
 they are expected to be documented in the other.
 </p>
 
@@ -218,11 +214,13 @@ access security.
 <h3><a name="2.2">2.2.</a> Physical Assets </h3>
 
 <ul class="q"><li>
-    Big question here is whether Oophaga falls inside SP/SM or not.<br>
-    Answered:  <b>IN</b>.
+    Big change is to place Oophaga INSIDE the SM/SP.
   </li><li>
-    2nd Big Question is whether Oophaga is in SP or in SM.<br>
-    Answered:  <b>in the SM.</b>
+    2nd Change is to place Oophaga in SP and in SM:
+    <ul>
+      <li> role of Access Engineer is in SP.</li>
+      <li> detail in the SM.</li>
+    </ul>
 </li></ul>
 
 <h4><a name="2.2.1">2.2.1.</a> Computers </h4>
@@ -247,14 +245,14 @@ Precautions must be taken to prevent equipment being
 prepared in advance.
 </p>
 
-<h4><a name="2.2.2">2.2.2.</a> Cables </h4>
-<p class="error">
-Drop  2.2.2.
-</p>
+<h4><a name="2.2.2">2.2.2.</a> Service </h4>
 
-<p class="q">
-Cabling to all equipment shall be labeled at both ends
-with identification of end points.
+<p class="q">Wytze:  new section replacing 'cables':</p>
+
+<p>
+Equipment that is subject to a service security risk
+must be retired if service is required.
+See also &sect;2.2.3.3.
 </p>
 
 <h4><a name="2.2.3">2.2.3.</a> Media </h4>
@@ -263,8 +261,7 @@ with identification of end points.
 
 <p>
 Storage media (disk drives, tapes, removable media)
-are inventoried upon acquisition
-and tracked in their use.
+are inventoried upon acquisition and tracked in their use.
 </p>
 
 <p>
@@ -305,7 +302,7 @@ The following steps are to be taken:
 Records of secure erasure and method of final disposal
 shall be tracked in the asset inventory.
 Where critical data is involved,
-2 system administrators must sign-off on each step.
+two systems administrators must sign-off on each step.
 </p>
 
 <h3><a name="2.3">2.3.</a> Physical Access </h3>
@@ -326,10 +323,11 @@ Access to physical equipment must be authorised.
 
 <p>
 The Security Manual must present the different access profiles.
-At least one CAcert systems administrator will be present for
-logical access to CAcert critical servers.
+At least one Access Engineer must control access in all cases.
+At least one systems administrator will be present for
+logical access.
 Only the most basic and safest of accesses should be done with
-one CAcert systems administrator present.
+one systems administrator present.
 </p>
 
 </p>
@@ -380,7 +378,7 @@ Only such services as are required for normal operation should be visible extern
 <h5> 3.1.1.2. Internal connectivity </h5>
 
 <p>
-System and server connections internal to the CAcert infrastructure should be kept to the minimum required for routine operations. Any new connectivity desired must be requested and approved by CAcert system administration team leader and then must be reflected in the appropriate infrastructure diagram(s).
+System and server connections internal to the CAcert infrastructure should be kept to the minimum required for routine operations. Any new connectivity desired must be requested and approved by system administration team leader and then must be reflected in the appropriate infrastructure diagram(s).
 </p>
 
 
@@ -424,7 +422,7 @@ Servers must enable only the operating system functions required to support the
 </p>
 
 <p>
-Documentation for installing and configuring servers with the appropriate software packages and configurations will be maintained by the system administrators in the wiki.
+Documentation for installing and configuring servers with the appropriate software packages and configurations will be maintained by the system administrators.
 </p>
 
 
@@ -460,15 +458,20 @@ Emergency patch events must be documented within the regular summaries to Board.
 <h3> 3.3. Application </h3>
 
 <p>
-Software development takes place on various test systems (not a critical system). See &sect;7. Once offered by Software Development (team), system administration team leader has to approve the installation of each release or patch.
+Software assessment takes place on various test systems (not a critical system). See &sect;7. Once offered by Software Assessment (team), system administration team leader has to approve the installation of each release or patch.
 </p>
 
 <p>
-Any changes made to source code must be referred back to software development.
+Any changes made to source code must be referred back to software assessment team.
 </p>
 
 <h3> 3.4. Access control </h3>
 
+	<p class="q">
+	  These two paras seem in wrong place.
+	  Either add a "3.4.3. User Access" or?
+	</p>
+
 <p>
 General user access to CAcert services shall normally be conducted through a web-based application interface. Features are made available according to Assurance Points and direct permissions.
 </p>
@@ -479,20 +482,50 @@ Direct Permissions are managed by the Application to enable special online admin
 
 <h4> 3.4.1. Authorisation </h4>
 
-<p>
-The access control lists are:
-</p>
+<p class="q"> This bit is expanded! </p>
+
+<p>
+The access control lists (see &sect;1.1.1) are:
+</p>
+
+<table align="center" border="1"> <tr>
+  <td>List Name</td>
+  <td>Who</td>
+  <td>Purpose of access</td>
+  <td>Relationship</td>
+  <td> Manager </td>
+ </tr><tr>
+  <td>Physical Control List</td>
+  <td>Access Engineers</td>
+  <td>control of access by personnel to hardware</td>
+  <td>exclusive of all other roles </td>
+  <td>Boards of CAcert and of Oophaga</td>
+ </tr><tr>
+  <td>Physical Access List</td>
+  <td>systems administrators</td>
+  <td>hardware-level for installation and recovery</td>
+  <td>exclusive with Access Engineers and Software Assessors</td>
+  <td>Boards of CAcert and of Oophaga</td>
+ </tr><tr>
+  <td>SSH Access List</td>
+  <td>systems administrators</td>
+  <td>Unix / account / shell level</td>
+  <td> includes by default all on Physical Access List </td>
+  <td>systems administration team leader</td>
+ </tr><tr>
+  <td>Support Access List</td>
+  <td>supporters</td>
+  <td>support features in the online interface</td>
+  <td> includes by default all systems administrators </td>
+  <td>systems administration team leader</td>
+ </tr><tr>
+  <td>Repository Access List</td>
+  <td>software assessors</td>
+  <td>change the source code repository</td>
+  <td>exclusive with Access Engineers and systems administrators</td>
+  <td>software assessment team leader</td>
+</tr><table>
 
-<ul><li>
-    Console Access List,
-    for physical access by System Administrators.
-  </li><li>
-    SSH Access List,
-    for access to Unix-level facilities of the online webserver.
-  </li><li>
-    Support Access List,
-    for access to the online support interface features.
-</li></ul>
 
 <p>
 All changes to the above lists are approved by the board of CAcert.
@@ -507,9 +540,8 @@ A strong method of authentication is used and documented.
 <h4> 3.4.3. Removing access </h4>
 
 <p>
-Termination actions must be documented,
-including resignation, arbitration, or determination
-by team or board.
+Follow-up actions to termination must be documented.
+See &sect;9.1.7.
 </p>
 
 
@@ -523,46 +555,38 @@ by team or board.
 Primary systems administration tasks
 shall be conducted under four eyes principle.
 These shall include backup performance verification,
-log inspection,
-software patch identification and application,
+software patch application,
 account creation and deletion,
 and hardware maintenance.
 </p>
 
-<p>
-System administrators must pass a background check
-and comply with all applicable policies in force.
-</p>
-
-<h4> <a name="4.1.1">4.1.1.</a> Privileged accounts and passwords </h4>
+<h4> <a name="4.1.1">4.1.1.</a> Privileged accounts and passphrases </h4>
 <p>
 Access to Accounts
 (root and user via SSH or console)
 must be strictly controlled.
-Passwords and passphrases entered into the systems will be kept private
+Passphrases and SSH private keys used for entering into the systems
+will be kept private
 to CAcert sysadmins in all cases.
 </p>
 
 <h5> <a name="4.1.1.1">4.1.1.1.</a> Authorized users </h5>
 <p>
-Only system administrators designated on the Access List
+Only system administrators designated on the
+Access Lists
+in &sect;3.4.1
 shall be authorized to access accounts.
 </p>
 
-<p class="q">Assumes above that there is no reason to have access
-to a Unix-level account on the critical machines unless on the Access List.</p>
-
 <h5> <a name="4.1.1.2">4.1.1.2.</a> Access to Systems</h5>
 <p>
-All remote communications for systems administration purposes is encrypted,
-logged and monitored.
+All access is secured, logged and monitored.
 </p>
 
 <h5> <a name="4.1.1.3">4.1.1.3.</a> Changing </h5>
 
 <p>
-Passwords must be kept secure.
-The procedure for changing passwords should be documented.
+The procedure for changing passphrases and SSH keys should be documented.
 </p>
 
 <h5> <a name="4.1.1.4">4.1.1.4.</a> Outsourcing </h5>
@@ -577,7 +601,7 @@ and are in good contact with team leader.
 
 <h4> <a name="4.1.2">4.1.2.</a> Required staff response time </h4>
 <p>
-Response times should be documented.
+Response times should be documented for Disaster Recovery planning.  See &sect;6.
 </p>
 
 <h4> <a name="4.1.3">4.1.3.</a> Change management procedures </h4>
@@ -594,20 +618,6 @@ All sensitive events should be logged.
 Logs should be deleted after an appropriate amount of time.
 </p>
 
-<p class="q">
-'''Move to SM:'''
-Logs shall be maintained for:
-</p>
-
-<ul>
-    <li> anomalous network traffic, </li>
-    <li> system activities and events, </li>
-    <li> application (certificate, web, mail, and database) events, </li>
-    <li> '''make generic''':  "Comms Module" requests for certificate signing on both the cryptographic module (signing server) and the main online server, </li>
-    <li> login and root access, </li>
-    <li> configuration changes.  </li>
-</ul>
-
 <h4> <a name="4.2.2">4.2.2.</a> Access and Security </h4>
 
 <p>
@@ -627,11 +637,12 @@ suspicious events should be flagged and investigated in a timely fashion.
 <h4> <a name="4.2.4">4.2.4.</a> Operational (manual) logs </h4>
 <p>
 Configuration changes, no matter how small, must be logged.
-Access to this log shall be restricted.
 </p>
 
 <p>
-All physical visits will be logged and a report provided by the accessor.
+All physical visits must be logged and a
+report provided by the accessor and by
+the Access Engineer.
 </p>
 
 <h3> <a name="4.3">4.3.</a> Backup </h3>
@@ -644,9 +655,9 @@ according to the following sub-headings.
 <h4> <a name="4.3.1">4.3.1.</a> Type </h4>
 <p>
 Backups must be taken for operational
-and for disaster recovery purposes ("offline").
-Disaster recovery backups must be offline and remote.
+and for disaster recovery purposes.
 Operational backups may be online and local.
+Disaster recovery backups must be offline and remote.
 </p>
 
 <h4> <a name="4.3.2">4.3.2.</a> Frequency </h4>
@@ -654,7 +665,7 @@ Operational backups may be online and local.
 <h4> <a name="4.3.3">4.3.3.</a> Storage </h4>
 <p>
 Backups must be protected to the same level as the critical systems themselves.
-Offline backups should be distributed.
+Disaster recovery backups may be distributed.
 </p>
 
 <h4> <a name="4.3.4">4.3.4.</a> Retention period and Re-use </h4>
@@ -682,9 +693,10 @@ Paper documentation must be stored with manual backups.
 
 <h4> <a name="4.3.8">4.3.8.</a> Reading Backups </h4>
 <p>
-Conditions and procedures for examining the backups for purposes
-other than for verification must be documented
-and must be under Arbitrator control.
+Conditions and procedures for examining the backups
+must be documented,
+and must be under Arbitrator control for purposes
+other than verification and recovery.
 </p>
 
 <h3> <a name="4.4">4.4.</a> Data retention </h3>
@@ -700,12 +712,10 @@ See CCA.
 
 <h4> <a name="4.4.3">4.4.3.</a> Incident reports </h4>
 <p>
-The systems administration team leader is to maintain incident reports securely.
-Access to incident reports is restricted.
+Document.
+See &sect;5.6.
 </p>
 
-<h3> <a name="4.5">4.5.</a> Cycling </h3>
-
 
 
 
@@ -755,18 +765,35 @@ Evidence must be secured if the severity is high.
 <h3> <a name="5.5">5.5.</a> Response </h3>
 
 <h3> <a name="5.6">5.6.</a> Report </h3>
+
 <p>
-A report should be appended to the documentation of the investigation,
-and distributed in the act of closing the investigation.
+Incident reports must be published.
+The Incident Report is written on closing the investigation.
+A full copy should be appended to the
+documentation of the investigation.
+Sensitive information may be pushed out into
+a restricted appendix of the report.
+The systems administration team leader is responsible
+for publication and maintenance.
 </p>
 
 <p>
-Incidents are not normally kept secret or confidential.
-Ony under a defined exception under policy,
+Incidents are not normally kept secret nor confidential.
+and progress information should be published as soon as
+possible.
+The knowledge of the existence of the event must not be kept
+secret, nor the manner and methods be kept confidential.
+</p>
+
+<p class="q">
+The following is a general confidentiality and secrecy
+clause.  Suggest moving this to new section 9.7.
+</p>
+
+<p>
+Only under a defined exception under policy,
 or under the oversight of the Arbitrator,
 may confidentiality be maintained.
-The knowledge of the existence of the event must not be kept
-secret, nor the manner in which it is kept confidential.
 </p>
 
 <h2><a name="6">6.</a> DISASTER RECOVERY</h2>
@@ -798,18 +825,19 @@ Board must have a basic plan to recover.
 <p>
 Board must maintain a key persons List with all the
 contact information needed.
+See &sect;10.1.
 </p>
 
 
 
-<h2><a name="7">7.</a> SOFTWARE DEVELOPMENT</h2>
+<h2><a name="7">7.</a> SOFTWARE ASSESSMENT</h2>
 
 <p class="q">
 Change name of this to Software Assessment.
 </p>
 
 <p>
-Software development team is responsible
+Software assessment team is responsible
 for the security of the code.
 </p>
 
@@ -817,7 +845,8 @@ for the security of the code.
 
 <p>
 The source code is under CCS.
-Additions to the team are approved by Board
+Additions to the team are approved by Board.
+See &sect;3.4.1.
 </p>
 
 <h3> <a name="7.2"> 7.2. </a> Tasks </h3>
@@ -837,7 +866,7 @@ The primary tasks are:
 </li></ol>
 
 <p>
-Software Development is not primarily tasked to write the code.
+Software assessment is not primarily tasked to write the code.
 In principle, anyone can submit code changes for approval.
 </p>
 
@@ -847,7 +876,7 @@ In principle, anyone can submit code changes for approval.
 <p>
 The application code and patches are maintained
 in a central repository that is run by the
-software development team.
+software assessment team.
 </p>
 
 <h3> <a name="7.4"> 7.4. </a> Review </h3>
@@ -865,16 +894,16 @@ The riskier the source is, the more reviews have to be done.
 <h3> <a name="7.5"> 7.5. </a> Test and Bugs </h3>
 
 <p>
-Software Development team maintains a test system.
+Software assessment team maintains a test system.
 Each patch should be built and tested.
 Test status of each patch must be logged.
 </p>
 
 <p>
-Software Development team maintains a bug system.
+Software assessment team maintains a bug system.
 Primary communications should go through this system.
-Management access should be granted to all software developers,
-and systems administrators.
+Management access should be granted to all software assessors,
+software developers, and systems administrators.
 Bug submission access should be provided to
 any Member that requests it.
 </p>
@@ -882,12 +911,12 @@ any Member that requests it.
 <h3> <a name="7.6"> 7.6. </a> Handover </h3>
 
 <p>
-Once signed off, software development (team leader)
+Once signed off, software assessment (team leader)
 coordinates with systems administration (team leader)
 to offer the upgrade.
 Upgrade format is to be negotiated,
 but systems administration naturally has the last word.
-Software development people are not to have access
+Software assessors are not to have access
 to the critical systems, providing a dual control
 at the teams level.
 </p>
@@ -903,7 +932,8 @@ system administrators.
 
 <p>
 Systems administrators copy the patches securely
-from the software development onto the critical machine.
+from the software assessment repository
+onto the critical machine.
 See &sect;3.3.
 </p>
 
@@ -929,8 +959,7 @@ by this policy or the Security Manual or other clear
 applicable document.
 If the Member's authority is not in doubt,
 the Member can give that authority.
-
-The Arbitrator's authority must be sought.
+If not, the Arbitrator's authority must be sought.
 </p>
 
 <p>
@@ -947,7 +976,8 @@ policies and practices.
 Access to Member's private information is restricted.
 Support staff may be authorised by the Board
 to access any additional, restricted interfaces.
-Each such special access is managed by the team leader.
+This access is managed by the systems administration
+team leader, see &sect;3.4.1.
 </p>
 
 <h3> <a name="8.5"> 8.5. </a> Records and Logs </h3>
@@ -968,8 +998,9 @@ Each such special access is managed by the team leader.
 <h3> <a name="9.1.1"> 9.1.1. </a> Roles and responsibilities</h3>
 
 <ul>
+    <li> Access Engineer: responsible for controlling access to hardware, and maintaining hardware. </li>
     <li> System administrator: responsible for maintaining core services and integrity. </li>
-    <li> Software Developer: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
+    <li> Software assessor: maintain the code base and confirm security ("sign-off") of patches and releases.</li>
     <li> Support: human interface with users.</li>
     <li> Team leaders: coordinate with teams, report to board.</li>
     <li> All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.</li>
@@ -979,13 +1010,16 @@ Each such special access is managed by the team leader.
 <h3> <a name="9.1.2"> 9.1.2. </a> Staffing levels</h3>
 
 <p>
-Each team should have a minimum of 2 members available at any time.
-Individuals should be active in only one team at any one time,
-but may be observers on any number of teams.
+Each team should have a minimum of two members available at any time.
+Individuals should not be active
+in more than one team at any one time,
+but are expected to observe the other teams.
+See &sect;3.4.1 for exclusivities.
 </p>
 
 <p>
-One individual in each team is designated leader and reports to Board.
+One individual in each team is designated team leader
+and reports to Board.
 </p>
 
 <h3> <a name="9.1.3"> 9.1.3. </a> Process of new Team Members</h3>
@@ -1034,7 +1068,7 @@ The background check should be done on all of:
 <ul>
     <li> systems administrator </li>
     <li> access engineeers </li>
-    <li> software developer </li>
+    <li> software assessor </li>
     <li> support </li>
     <li> Board </li>
 </ul>
@@ -1052,11 +1086,11 @@ It must include:
 </p>
 
 <ul>
-    <li> agreement with appropriate policies, etc </li>
-    <li> contact information </li>
+    <li> Agreement with appropriate policies, etc. </li>
+    <li> Contact information. See &sect;10.1. </li>
 </ul>
 
-<h4> <a name="9.1.4.4"> 9.1.4.4. </a> Privacy for Hard Roles</h4>
+<h4> <a name="9.1.4.4"> 9.1.4.4. </a> Privacy for Critical Roles</h4>
 
 <p>
 The following privacy considerations exist:
@@ -1114,6 +1148,16 @@ and may be reversed.
 Termination of access may be for resignation, Arbitration ruling,
 or decision of Board or team leader.
 On termination (for any reason), access and information must be secured.
+See &sect;3.4.3.
+</p>
+
+<p>
+The provisions on Arbitration survive any termination
+by persons fulfilling a critical role.
+That is, even after a person has left a critical role,
+they are still bound by the DRP (COD7),
+and the Arbitrator may reinstate any provision
+of this agreement or bind the person to a ruling. 
 </p>
 
 <h3> <a name="9.1.8"> 9.1.8. </a> HR and Training</h3>
@@ -1188,7 +1232,13 @@ All external inquiries of security import are filed as disputes and placed befor
 </p>
 
 <p>
-Only the Arbitrator has the authority to deal with external requests and/or create a procedure. Systems administrators, board members and other key roles do not have the authority to answer legal inquiry. The Arbitrator's ruling may instruct individuals, and becomes your authority to act. 
+Only the Arbitrator has the authority
+to deal with external requests and/or create a procedure.
+Access Engineers, systems administrators,
+board members and other key roles
+do not have the authority to answer legal inquiry.
+The Arbitrator's ruling may instruct individuals,
+and becomes your authority to act. 
 </p>
 
 <h3><a name="9.6">9.6.</a> Outsourcing </h3>
@@ -1212,7 +1262,7 @@ All arrangements must be:
     under Arbitration and DRP,
   </li><li>
     with organisations that are Members of CAcert
-    as organisational Members,
+    as organisational Members, and
   </li><li>
     under the spirit of the Principles of CAcert
 </li></ul>
@@ -1239,7 +1289,7 @@ All incorporated Documents must be documented.
 
 <h3> <a name="10.3">10.3</a> Related Documents </h3>
 <p>
-Relevant and helpdul Documents should be referenced for convenience.
+Relevant and helpful Documents should be referenced for convenience.
 </p>