diff --git a/docs/concepts/policy/pod-security-policy.md b/docs/concepts/policy/pod-security-policy.md
index cf56b9900c..884ad55fc6 100644
--- a/docs/concepts/policy/pod-security-policy.md
+++ b/docs/concepts/policy/pod-security-policy.md
@@ -171,86 +171,8 @@ make sure `volumes` contains the `flexVolume` volume type, no flex volume driver
 otherwise. For example:
 
 ```yaml
-# Authorize all service accounts in a namespace:
-- kind: Group
-  apiGroup: rbac.authorization.k8s.io
-  name: system:serviceaccounts
-# Or equivalently, all authenticated users in a namespace:
-- kind: Group
-  apiGroup: rbac.authorization.k8s.io
-  name: system:authenticated
-```
-
-For more examples of RBAC bindings, see [Role Binding
-Examples](/docs/admin/authorization/rbac/#role-binding-examples). For a complete
-example of authorizing a PodSecurityPolicy, see
-[below](#example).
-
-
-### Troubleshooting
-
-- The [Controller Manager](/docs/admin/kube-controller-manager/) must be run
-against [the secured API port](/docs/admin/accessing-the-api/), and must not
-have superuser permissions. Otherwise requests would bypass authentication and
-authorization modules, all PodSecurityPolicy objects would be allowed, and users
-would be able to create privileged containers. For more details on configuring
-Controller Manager authorization, see [Controller
-Roles](/docs/admin/authorization/rbac/#controller-roles).
-
-## Policy Order
-
-In addition to restricting pod creation and update, pod security policies can
-also be used to provide default values for many of the fields that it
-controls. When multiple policies are available, the pod security policy
-controller selects policies in the following order:
-
-1. If any policies successfully validate the pod without altering it, they are
-   used.
-2. Otherwise, the first valid policy in alphabetical order is used.
-
-## Example
-
-_This example assumes you have a running cluster with the PodSecurityPolicy
-admission controller enabled and you have cluster admin privileges._
-
-### Set up
-
-Set up a namespace and a service account to act as for this example. We'll use
-this service account to mock a non-admin user.
-
-```shell
-$ kubectl create namespace psp-example
-$ kubectl create serviceaccount -n psp-example fake-user
-$ kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user
-```
-
-To make it clear which user we're acting as and save some typing, create 2
-aliases:
-
-```shell
-$ alias kubectl-admin='kubectl -n psp-example'
-$ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'
-```
-
-### Create a policy and a pod
-
-Define the example PodSecurityPolicy object in a file. This is a policy that
-simply prevents the creation of privileged pods.
-
-{% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}
-
-And create it with kubectl:
-
-```shell
-$ kubectl-admin create -f example-psp.yaml
-```
-
-Now, as the unprivileged user, try to create a simple pod:
-
-```shell
-$ kubectl-user create -f- <<EOF
-apiVersion: v1
-kind: Pod
+apiVersion: extensions/v1beta1
+kind: PodSecurityPolicy
 metadata:
   name: allow-flex-volumes
 spec:
diff --git a/docs/tasks/debug-application-cluster/audit.md b/docs/tasks/debug-application-cluster/audit.md
index a47fc04c9b..b5044cfa32 100644
--- a/docs/tasks/debug-application-cluster/audit.md
+++ b/docs/tasks/debug-application-cluster/audit.md
@@ -37,48 +37,11 @@ of rules in order. The first matching rule sets the [audit level][auditing-level
 of the event. The audit policy object structure is defined in the
 [`audit.k8s.io` API group][auditing-api].
 
-`AdvancedAuditing` is customizable in two ways. Policy, which determines what's recorded,
-and backends, which persist records. Backend implementations include logs files and
-webhooks.
-
-The structure of audit events changes when enabling the `AdvancedAuditing` feature
-flag. This includes some cleanups, such as the `method` reflecting the verb evaluated
-by the [authorization layer](/docs/admin/authorization/) instead of the [HTTP verb](/docs/admin/authorization/#determine-the-request-verb).
-Also, instead of always generating two events per request, events are recorded with an associated "stage".
-The known stages are:
-
-- `RequestReceived` - The stage for events generated as soon as the audit handler receives the request.
-- `ResponseStarted` - Once the response headers are sent, but before the response body is sent. This stage is only generated for long-running requests (e.g. watch).
-- `ResponseComplete` - Once the response body has been completed.
-- `Panic` - Events generated when a panic occurred.
-
-### Audit Policy
-
-Audit policy is a document defining rules about what events should be recorded.
-The policy is passed to the [kube-apiserver][kube-apiserver] using the
-`--audit-policy-file` flag.
-
-```
---audit-policy-file=/etc/kubernetes/audit-policy.yaml
-```
-
-If `AdvancedAuditing` is enabled and this flag is omitted, no events are logged.
-
-The policy file holds rules that determine the level of an event. Known audit levels are:
-
-- `None` - don't log events that match this rule.
-- `Metadata` - log request metadata (requesting user, timestamp, resource, verb, etc.) but not request or response body.
-- `Request` - log event metadata and request body but not response body.
-- `RequestResponse` - log event metadata, request and response bodies.
-
-When an event is processed, it's compared against the list of rules in order.
-The first matching rule sets the audit level of the event. The audit policy is
-defined by the [`audit.k8s.io` API group][audit-api].
-Some new fields are supported in beta version, like `resourceNames` and `omitStages`.
-
-In Kubernetes 1.8 `kind` and `apiVersion` along with `rules` __must__ be provided in
-the audit policy file. A policy file with 0 rules, or a policy file that doesn't provide
-a valid `apiVersion` and `kind` value will be treated as illegal.
+You can pass a file with the policy to [kube-apiserver][kube-apiserver]
+using the `--audit-policy-file` flag. If the flag is omitted, no events are logged.
+__Note:__ `kind` and `apiVersion` fields along with `rules` __must__ be provided
+in the audit policy file. A policy with no (0) rules, or a policy that doesn't
+provide valid `apiVersion` and `kind` values is treated as illegal.
 
 Some example audit policy files: