Process/Engineering/SecurityIntake.md

+# Security intake process
+
+This page describes the process for handling security issues when they are reported via the `security@torproject.org` alias. It describes who is responsible what they are responsible for and the process that will be followed from initial submission to resolution.
+
+# Security point people
+
+Each team lead identifies a security point person from their team to be the responsible party for their team. This can be the team lead, or someone else in the team. This person is responsible for timely intake of issues related to the team. Although security issues reported this way are infrequent, ignoring these can be disastrous. This person is simply ensuring that the process is activated for the team, and not solely responsible for triage, evaluation and resolution of these issues. 
+
+# OpenPGP role key
+
+A [Tor Security "role" OpenPGP key](process/engineering/SecurityRoleKey) is generated for the uid `security@torproject.org` and its fingerprint is published on the [Tor Project's help pages](https://support.torproject.org/misc/bug-or-feedback) detailing how to report a security issues. It is up to the reporter to encrypt the mail to the alias with this key, encryption is encouraged, but not required.
+
+The OpenPGP secret key material for the `security@torproject.org` UID is distributed to the security point people, so they can decrypt any encrypted mail.
+
+If an individual who is a security point person is no longer working with Tor, or needs to otherwise rotate out of this role, then they are to be replaced with a new person from that team and the key material is rotated and redistributed. 
+
+# Intake process
+
+When a security issue arrives to `security@`, the team security point person should create a confidential issue in the appropriate gitlab project, with the `Security` label. If this person is on vacation, then another point-person could optionally step in and route the issue to the correct team.
+
+Teams should then begin an evaluation process to determine its relative severity and priority. 
+
+As necessary, convene a meeting of subject matter stake-holders to triage, or integrate this process into regular team meetings (respecting confidentiality). Team leads should make sure this process goes smoothly, and route help as needed. 
+
+The issue **must** be assigned to someone, it should also have its severity/priority set and an expiration date for when the issue should be resolved. An issue without an assignee can be easily lost.
+
+Because security issues need to be properly addressed in a timely manner they should be continuously evaluated in scoping sessions so they are not dropped.