diff --git a/security.md b/security.md
deleted file mode 100644
index da4da20b3c8..00000000000
--- a/security.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-assignees:
-- eparis
-- erictune
-
----
-
-If you believe you have discovered a vulnerability or a have a security incident to report, please follow the steps below. This applies to Kubernetes releases v1.0 or later.
-
-To watch for security and major API announcements, please join our [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group.
-
-## Reporting a security issue
-
-To report an issue, please:
-
-- Submit a bug report [here](http://goo.gl/vulnz).
-  - Select 'I want to report a technical security bug in a Google product (SQLi, XSS, etc.).'?
-  - Select 'Other'? as the Application Type.
-- Under reproduction steps, please additionally include
-  - the words "Kubernetes Security issue"
-  - Description of the issue
-  - Kubernetes release (e.g. output of `kubectl version` command, which includes server version.)
-  - Environment setup (e.g.  which "Getting Started Guide" you followed, if any; what node operating system used; what service or software creates your virtual machines, if any)
-
-An online submission will have the fastest response; however, if you prefer email, please send mail to security@google.com. If you feel the need, please use the [PGP public key](https://services.google.com/corporate/publickey.txt) to encrypt communications.
-
-
-
diff --git a/security/index.md b/security/index.md
new file mode 100644
index 00000000000..5fe3b5b13cd
--- /dev/null
+++ b/security/index.md
@@ -0,0 +1,46 @@
+---
+layout: docwithnav
+title: Kubernetes Security and Disclosure Information
+permalink: /security/
+assignees:
+- eparis
+- erictune
+- philips
+- jessfraz
+---
+
+## Security Announcements
+
+Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group for emails about security and major API announcements.
+
+## Report a Vulnerability
+
+We’re extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
+
+To make a report, please email the private [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) list with the security details and the details expected for [all Kubernetes bug reports](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE.md).
+
+You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure.
+
+### When Should I Report a Vulnerability?
+
+- You think you discovered a potential security vulnerability in Kubernetes
+- You are unsure how a vulnerability affects Kubernetes
+- You think you discovered a vulnerability in another project that Kubernetes depends on (e.g. docker, rkt, etcd)
+
+### When Should I NOT Report a Vulnerability?
+
+- You need help tuning Kubernetes components for security
+- You need help applying security related updates
+- Your issue is not security related
+
+## Security Vulnerability Response
+
+Each report is acknowledged and analyzed by Product Security Team members within 3 working days. This will set off the [Security Release Process](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst).
+
+Any vulnerability information shared with Product Security Team stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
+
+As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated.
+
+## Public Disclosure Timing
+
+A public disclosure date is negotiated by the Kubernetes product security team and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes product security team holds the final say when setting a disclosure date.