Question regarding how to handle large tables with many rows: 


Where should the delete option be? I see many examples placing the delete icon or text on the far-right of the row. Is this best practice? Is it always advisable to swap row delete to checkbox selection/batch delete?
If a table row has multiple available actions such as [Edit | Publish | View History ] etc, should these items be grouped into a single "Actions" row item? 



Question: Is it possible to cryptographically prove when was the last time a ciphertext was decrypted/encrypted?
Answer: Updated answer:

No, this is not possible with cryptography.
You have the ciphertext and you have the key.
For all anyone knows, you could have made a copy of those to some other computer and decrypted the ciphertext without telling anyone.
There's no way (with cryptography) to prove you haven't done that.

One approach would be to implement a secure service and hire an independent auditor to audit your code and architecture and certify that you appear to have set things up in a way that protects your customers' data.  You could hire an independent security pro to review your system and write a public report that customers can view.  I don't know if this would give potential customers a better sense of comfort or if it would be worth the money.

The only approach I can think of, to solve this through technical means, would be to use trusted computing.  Trusted computing relies upon trusted hardware (TPMs), and its support for remote attestation would allow you to prove to others what code you are running.  You could publish the source to your software to allow anyone to verify that your software doesn't make a copy of their keys or their data, and use remote attestation to prove that you're using that good software.

However, using trusted computing in this way is extremely complicated.  Trusted computing is bleeding-edge stuff; it's an engineering and management hassle of major proportions.  Moreover, most customers probably won't have the patience, skills, or desire to undertake all of the tasks that would be required to verify that your system works properly.

So, I think there's no technical solution for your problem.  You'll have to rely upon your customer's trust, your reputation, contractual guarantees, and other social/legal means, instead of technical solutions.

A comment: your problem is more an information security problem than a cryptography problem.  Are you familiar with IT Security?



Original answer:

I think you need to define the problem better, to identify who are the principals/participants and what is the threat model.

If the decryptor knows the ciphertext and decryption key and wants to subvert the protocol, you cannot prove that the decryptor didn't decrypt the ciphertext.

The decryptor can prove that he did decrypt the ciphertext (using a zero-knowledge proof of knowledge, possibly with some timestamping).  However, he cannot prove that he read the decrypted message or paid attention to it or acted on it, so I suspect this will be basically useless in practice.

If you can limit access to the ciphertext or the decryption key, then you can prove some partial statements.  For instance, if you don't release the ciphertext to anyone until time $t$, you can prove that no one could possibly have decrypted it before time $t$.  If you know the key, though, you won't be able to prove that you didn't release it before time $t$ (except possibly through use of TPMs / trusted computing), so you'll probably need to be trusted for this to be meaningful.

There are many other possible scenarios -- to propose a specific solution, we'll probably need to know the threat model and requirements in a bit more detail.