\begin{enumerate}[label={9.\arabic*}]
	\item\fail{} Verify that all forms containing sensitive information
		have disabled client side caching, including autocomplete
		features.

		\begin{result}
			The login and page/post editing/creation forms post back to the same page, thereby incentivising the browser to cache the form inputs as well. This is as opposed to the common post/redirect/get model (see \url{http://en.wikipedia.org/wiki/Post/Redirect/Get}). Also, the \texttt{Cache-Control} isn't explicitly used anywhere in the CMS to aid the situation. In my test setup, the response does send \texttt{Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0}, but that'll be a default global Apache setting, I think.
		\end{result}

	\notapplicable{\item Verify that the list of sensitive data processed by the
		application is identified, and that there is an explicit
		policy for how access to this data must be controlled,
		encrypted and enforced under relevant data protection
		directives.}

	\item\pass{} Verify that all sensitive data is sent to the server in the
		HTTP message body or headers (i.e., URL parameters are
		never used to send sensitive data).

		\begin{result}
			With the exception of the install script, which we treat separately as explained above, this is indeed the case.
		\end{result}

	\item\fail{} Verify that the application sets appropriate anti-caching
		headers as per the risk of the application, such as the
		following:
		\begin{verbatim}
			Expires: Tue, 03 Jul 2001 06:00:00 GMT
			Last-Modified: {now} GMT
			Cache-Control: no-store, no-cache, must-
			revalidate, max-age=0
			Cache-Control: post-check=0, pre-check=0
			Pragma: no-cache
		\end{verbatim}

		\begin{result}
			Cache control header are never set by the CMS. The fact that headers as these are indeed sent to the broswer in my test setup is probably due to default global Apache settings.
		\end{result}

	\item\pass{} Verify that on the server, all cached or temporary copies
		of sensitive data stored are protected from unauthorized
		access or purged/invalidated after the authorized user
		accesses the sensitive data.

		\begin{result}
			Vacuously.
		\end{result}

	\notapplicable{\item Verify that there is a method to remove each type of
		sensitive data from the application at the end of the
		required retention policy.}

	\item\pass{} Verify the application minimizes the number of
		parameters in a request, such as hidden fields, Ajax
		variables, cookies and header values.

		\begin{result}
			The CMS by no means sends any larger amount of parameters than would be expected, seen as it is but a simple app and mostly lacks extra functionality often leading to this kind of excessive parameter transferring, so I count this as a pass.
		\end{result}

	\notapplicable{\item Verify the application has the ability to detect and alert
		on abnormal numbers of requests for data harvesting for
		an example screen scraping.}

	\item\pass{} Verify that data stored in client side storage (such as
		HTML5 local storage, session storage, IndexedDB, regular
		cookies or Flash cookies) does not contain sensitive data
		or PII.

		\begin{result}
			Vacuously: data is not stored on the client side.
		\end{result}

	\item\pass{} Verify accessing sensitive data is logged, if the data is
		collected under relevant data protection directives or
		where logging of accesses is required.

		\begin{result}
			No logging occurs at all.
		\end{result}

	\item\pass{} Verify that sensitive information maintained in memory
		is overwritten with zeros as soon as it no longer required,
		to mitigate memory dumping attacks.

		\begin{result}
			I consider this outside of the scope of the CMS's security requirements, as it is written in, and thus relies on the (memory) security of, PHP.
		\end{result}

\end{enumerate}
