= Incident i20141011.1 = * Incident Number: i20141011.1 * Status: closed * Incident Manager: Benedikt Heintel * Date of incident opened: 2014-10-11 * Date of incident closed: 2015-08-12 * Incident title: Support team does not follow established process == History Log == . 20141011: Created and finished Incident 20141011.1 . 20141012: Updated root cause analysis with more information and further evidence documented in [[Audit/Incidents/priv/i20141011.1|private part]] . 20141102: Updated root cause analysis with further information . 20141113: Added further thoughts in root cause analysis. == 1. Incident Response Team == . internal Auditor . 1 Support team member . 2 Arbitrators == 2. Incident Description == An Arbitrator mentioned in an e-mail that a support team member does not follow any of the established (ruled by precedent cases) processes for account deletion. The support team member locked the member's account to be deleted for a retention period, since the last certificate is either still valid or expired not more than three month ago. In accordance to [[Support/Handbook/PrecedentCases/a20111128.3|the support lesson on Precedence Case a20111128.3]]. It states {{{ Lock the account for the retention time. (Needs to be clarified by arbitrations) }}} There are two questions to be answered: 1. Is support's process compliant with the process outlined by arbitration? 1. Is the termination of the CCA done by closing the account valid with this process? == 3. Containment Actions == No action was done to contain the incident, there is no current danger. If the owner of the account to be deleted has an issue, he should contact Arbitration. == 4. Root Causes == A delete account request can in accordance to [[http://www.cacert.org/policy/CAcertCommunityAgreement.php|CAcert's Community Agreement (CCA)]] only executed by an arbitrator. The Arbitrator of a case is able to delegate the task once or for all upcoming similar cases to another team. The delete account was delegated to support due to the rulings of [[Arbitrations/a20111128.3|a20111128.3]] (precedence case for account deletion), [[Arbitrations/a20140713.1|a20140713.1]] (precedence case for Assurer account deletion where last assurance is more than 7 years ago) and [[Arbitrations/a20140123.1|a20140123.1]] (precedence case for assurer account deletion with last assurance less than 7 years ago). The two later precedence rulings refer to the first, since they are special cases of the first. Therefore, this incident is concentrated on the first precedence case. The arbitration case itself says nothing about what happens during the retention period, the support lesson clearly defines the status that there is a ruling missing if the member's account is allowed to be locked or not. From the mailing send to the member, support gives the reason to lock the account for security purposes: {{{ Meanwhile I will lock your account so nobody except support is able to access your account. If you would change your mind in the meantime, it would be easy to unlock your account. }}} The Arbitrator of [[Arbitrations/a20111128.3|a20111128.3]] provided the Auditor additional information about the creation of named case: The 'delete account' process bases on a couple of singular arbitration decisions between 2010 and 2012. It started with an Assurer Team meeting or appeal court in [[Arbitrations/Meetings/ATAgendaandMinutes-20100104|January 2010]] where ideas how to do delete an account and terminate [[http://www.cacert.org/policy/CAcertCommunityAgreement.php|CCA]] have been initially discussed. Several arbitrations thereafter handled account deletion. This account lock follows arbitration cases such as [[Arbitrations/a20090510.3|a20090510.3]], [[Arbitrations/a20090618.3|a20090618.3]], [[Arbitrations/a20110131.1|a20110131.1]], [[Arbitrations/a20110502.1|a20110502.1]], [[Arbitrations/a20110110.1|a20110110]], [[Arbitrations/a20111128.3|a20111128.3]] where an arbitrator explicitly ruled so. The phrase retention lock is introduced to the [[Support/Handbook/PrecedentCases/a20111128.3?action=diff&rev1=12&rev2=13|Support Handbook]] on 2012-01-07. Arbitration's goal at this time was that an account stays in the 'as is status' while there is still the possibility to hold an account without introducing further risk. The later precedence case [[Arbitrations/a20111128.3|a20111128.3]] was clarifying this; named precedence case is only highlighting the hold period and not re-discussing the lock or other aspects. For the Arbitrator of [[Arbitrations/a20111128.3|a20111128.3]], the account lock went lost when the case became a precedence case. To change the precedence case, either the case need to be appealed or another delete account case need to be ruled by Arbitration. Both are unrealistic. The claimant is not interested in the procedure, only in the outcome and there should be no-one else having a right to appeal this case. Since this precedence case, all similar cases are handled by Support and none is given to arbitration to improve precedence's ruling. ''further information follow, when report is accepted by CAcert's committee.'' == 5. Permanent Corrective Actions == There is no non-conformity found in this incident evaluation. Therefore, no corrective actions apply. == 6. Verify Corrective Actions == N/A == 7. Preventive Actions == The Auditor recommends: 1. support to pass one delete account through to Arbitration to clarify the lock account or a milder method, 1. to attach a process diagram to the process description in the [[Support/Handbook/PrecedentCases/a20111128.3|support handbook]]. == 8. Approval & Closure == || '''Approved''' || 2015-08-11 [[https://community.cacert.org/board/motions.php?motion=m20150803.2|m20150803.2]] || || '''Date closed''' || 2015-08-12 || ---- . CategoryAudit . CategoryIncident