But even at such an especially sensitive time, civil servants do not have to be entirely candid. They should, "as far as possible, be straightforward", the guidelines say.
As if keeping to the guidelines, the Ministry of Defence responded at length to the House of Commons Public Accounts Committee in a report published last week.
The MoD report replies to criticism that the Chinook Mk2 helicopter, the type involved in the 1994 Mull of Kintyre crash, may have been put into operational service while unsafe.
Twenty-nine people, including all four crew and 25 members of the police and intelligence services, were killed.
A campaign by Computer Weekly has highlighted evidence that raises doubt over the reliability of the software control systems used in the type of helicopter that crashed.
David Davis, chairman of the committee said the MoD report was "not so much of a rebuttal as an ignoral".
In November last year, the Public Accounts Committee committee published its findings on the acceptance into service of a range of military equipment, from ships to telecommunications and radar systems. The committee examined whether the needs of users had been met by the equipment bought.
In particular the MPs studied the acceptance into service of the Chinook Mk2, with its problematic full authority digital engine control software system, Fadec.
They concluded that the "problems experienced during the Chinook Mk2 acceptance process coincide with, and are relevant to the tragic crash of Chinook ZD-576 into the Mull of Kintyre on 2 June 1994."
The committee found that there was too little firm evidence to say that the crash was caused by Fadec, but nevertheless declared that there was sufficient doubt over the system to suggest that the MoD's decision to blame the pilots was wrong.
"At the time of the crash," said the committee, "the Chinook Mk2 was experiencing repeated and unexplained technical difficulties caused by the Fadec software.
"The technical data recovered from the wreckage was incomplete and does not, we believe, conclusively rule out a technical malfunction as a potential cause of the crash."
It added that its conclusions "also raise wider issues relating to the... department's capability to act as a truly intelligent customer when accepting equipment that incorporates and relies on complex software systems". The committee was particularly concerned about the MoD's reliance on manufacturers when "investigating faults and accidents".
In response, the MoD chose its words carefully and changed its language depending on the context.
For example, when disparaging its own IT and airworthiness assessors who found the Fadec software "unverifiable", it referred to them as "Boscombe Down".
But when seeking to show how the MoD received independent specialist advice on the Fadec and the helicopter, it referred to Boscombe Down's parent organisation, the Defence Evaluation Research Agency.
The Pubic Accounts Committee may now decide to call the MoD back to answer further questions on the crash and the events surrounding it.
Discrepancies between the MoD report and facts uncovered by Computer Weekly leave some key questions unanswered
The Department notes the [Public Accounts] Committee's conclusions but does not accept the committee's view that the Chinook Mk2 acceptance process was flawed. The Chinook Mk2 programme was delivered on time, below budget
This makes no clear distinction between the Fadec project, which encountered serious delays, lost savings and technical problems, and the conversion of the Chinook Mk1 to Mk2 which was originally a separate contract.
Initially the MoD and the Chinook's prime contractor, Boeing, had planned to install Fadec long before the project to convert the Chinook Mk1 to Mk2, which was termed the mid-life update. But when the Fadec project ran late the MoD decided against installing the Fadec on the Chinook Mk1 and instead rolled it into the later Mk1 to Mk2 midlife update.
That the Fadec programme was seriously delayed is not in dispute. Avco Lycoming, the Fadec supplier, had promised the MoD that "production delivery of Fadec systems for retrofit aircraft will be available 24 months after go-ahead". The go-ahead was given in 1985, so the Fadec should have been ready for fitting in 1987. In fact was not ready until 1989, but during a ground test at Wilmington, US, a problem caused the near destruction of an MoD Chinook.
This led the UK Defence Procurement Office in Washington to write to Lycoming in March 1989, warning that the Fadec project may be cancelled. "This [accident] has resulted in the UK reconsidering our strategy for the future of the Fadec system and we will not be committing further funds until the results of the critical design review are clear," it said.
In the end, the production contract for Fadec was not placed until 1991. Delays attributable directly to the accident in 1989 amounted to nine months. Based on the estimates of the savings by Boeing and Lycoming, the MoD lost $2.55m (£1.78m) - nine twelfths of the anticipated annual savings of $3.4m (£2.38m) - as a result of the system's delays.
MoD internal documents dated 1995 said that even after the production version of Fadec was delivered, there were "flaws in the new system" so "no regular pattern of operating and maintenance costs has as yet been established". So the MoD's claim that the Chinook Mk2 programme was delivered on time may be misleading and glosses over subsequent software problems.
The Chinook Mk2 acceptance process was conducted incrementally, managing risk by initially operating with a reduced flight envelope.
This refers to imposing a weight restriction which was in place for several years after the introduction of the Chinook Mk2 so that if Fadec caused one engine to fail, the helicopter would be able to operate safely on its remaining engine. The restriction was the MoD's solution to the concerns of its IT advisers at Boscombe Down.
But MoD documents which have come to light since the crash on the Mull show that the Fadec was capable of causing both a straightforward engine shut-down and also other unpredictable problems.
For example, MoD air publication notices highlighted by Computer Weekly earlier this month reflected internal concern that the Fadec could prevent pilots obtaining maximum engine power when they needed it, or could cause an engine surge when the system was in its "reversionary" or back-up mode. In an engine surge, the pilots need to coarsen the angle of the rotor blades to bring down their speed, which can force a low-level aircraft into cloud - weight restrictions would not help pilots in an engine surge.
Although fire damage prevented assessment of the number one digital engine control unit (Decu) [part of the Fadec] the number two Decu remained partially functional. Its memories showed no abnormal exceedances had been detected over its life and that no faults had been detected on the last flight.
This could be misleading because it does not make clear that the above assurances on the lack of faults on the Fadec were made not by the chief crash investigator but by the system's manufacturers.
Nor does it mention that the crash investigator, when eliciting the help of the manufacturers, was unaware that they were being sued by the MoD over the faulty design of Fadec.
There was no evidence at the time that software or mechanical problems were the cause of the accident, and the Department is satisfied that this continues to be the position É it was their duty [that of two air marshals] to reach an honest conclusion based upon the evidence. This is what they did [ in blaming the pilots].
This implies that the RAF Board of Inquiry ruled out technical malfunction as a possible cause of the accident. It did not. It said a major technical malfunction could not be discounted as a possible factor.
Of more long-term import is the MoD's conclusion that pilots can be blamed unless there is unequivocal contrary evidence of a major malfunction.
The US Army, computer specialists, and the RAF Board of Inquiry have said it is possible for software to malfunction in a way which leaves no physical evidence. By the MoD's logic, therefore, it is possible to blame human error for any military accident such an accidental missile firing which may be caused by an untraceable software malfunction.