We'll hope this is for legal purposes.
256 = 7 x 1016 choices.
If you can do 3 billion (3GHZ) tests a second.
Then it would take about 8 months to go through all the choices. Whew, I thought it would be longer, but I suppose that is why you chose not to do 64 bit or 128 bit encryption. Still, you will need an efficient tight loop, and good parallel processing.
This is one of the reasons that most searches first begin with heuristic based searches. Look for common names and dictionary words before slogging through brute force. Also, if the code is made up of 7 bytes, you might restrict your search to printable characters. Are there any characters that are not allowed by the encryption algorithm such as "return"?
This is one reason why it may be best to input codes in hex if octal or hex if possible.
Anyway, it would help to know a little about the document being decoded.
If it is an MS Word document, perhaps look for particular characters in the header file.
If it is "text", then run the output through a spell checker. Or, look for repeating characters such as a space that would repeat on regular intervals, usually less than every 10 characters or so.
If it is a hard drive, then look for specific system programs on the drive, or directory constructs.
Making a code within a code would make it much more difficult to crack. And, of course, it helps to know the encryption algorithm.