diff --git a/doc/dbus-api-design.duck b/doc/dbus-api-design.duck
index be3ea9fd..84ff29f9 100644
--- a/doc/dbus-api-design.duck
+++ b/doc/dbus-api-design.duck
@@ -826,6 +826,8 @@ however there are some steps which you can take when designing an API to ease
 security policy implementation.
 
 D-Bus security policies are written as XML files in
+$file($var($$(datadir$)/dbus-1/system.d)),
+$file($var($$(datadir$)/dbus-1/session.d)),
 $file($var($$(sysconfdir$)/dbus-1/system.d)) and
 $file($var($$(sysconfdir$)/dbus-1/session.d)) and use an allow/deny model, where
 each message (method call, signal emission, etc.) can be allowed or denied
@@ -836,7 +838,10 @@ $code(send_destination) or $code(receive_sender) attribute set.
 When designing an API, bear in mind the need to write and install such a
 security policy, and consider splitting up methods or providing more restricted
 versions which accept constrained parameters, so that they can be exposed with
-less restrictive security policies if needed by less trusted clients.
+less restrictive security policies if needed by less trusted clients. Since
+dbus-daemon 1.10, security policies should be installed to
+$file($var($$(datadir$))) rather than $(file($var($$(sysconfdir$))); the latter
+is intended for system administators.
 
 Secondly, the default D-Bus security policy for the system bus is restrictive
 enough to allow sensitive data, such as passwords, to be safely sent over the
diff --git a/doc/system-activation.txt b/doc/system-activation.txt
index dd195f75..dde648e8 100644
--- a/doc/system-activation.txt
+++ b/doc/system-activation.txt
@@ -46,7 +46,8 @@ Exec=/usr/sbin/dbus-test-server.py
 User=ftp
 
 This gives the user to switch to, and also the path of the executable.
-The service name must match that specified in the /etc/dbus-1/system.d conf file.
+The service name must match that specified in the /etc/dbus-1/system.d or
+/usr/share/dbus-1/system.d conf file.
 
 Precautions taken: