does SPI delay between functions affect the communication correctness
The short answer to "will it be false" is, maybe - but it's very case specific.

In general, SPI should exhibit no problems with delays between the steps you've noted.  The clock only runs when data is being exchanged, and the clock can run down to DC.  Even if you were using an RTOS and a software (bit-banged) SPI implementation and a few clocks into exchanging a byte the task doing the software SPI transfer was paused by the scheduler and restarted later, the slave shouldn't care.

That said, there are implementation issues with particular types of SPI slave.  For example, I've used SPI ADC's that use the /CS assertion to start the sample &amp; hold process and the SPI clock as the successive approximation clock.  If the SA clock was to be run too slowly, the voltage caught by S&amp;H would leak away.  In your case, with a comms peripheral like CAN, you might lose received messages because the CAN peripheral can buffer only so many messages before it has to start discarding any new ones, and at 1Mbps you can get quite a few CAN messages in 5ms.

One of the tidiest ways to deal with these issues (particularly for a comms peripheral) is to use a combination of interrupts and (if your MCU supports it) DMA.

Your CAN controller probably has some kind of "attention" flag that it can raise to the host MCU to tell it that message/s are waiting to be read.  The "attention" flag raises an interrupt in the MCU, which then asserts /CS and starts a DMA transaction to read the message/s.  When the DMA transaction completes the DMA controller raises an interrupt to tell the MCU to de-assert /CS and check it's SPI receive buffer.

If your MCU doesn't have a DMA controller but does have a hardware SPI peripheral, then you can (or should be able to) use interrupts; as each SPI exchange completes (typically 1 byte, but sometimes more) the SPI peripheral raises an interrupt and the MCU can choose to start another exchange or complete the entire transaction.

I'll add that (hardware) SPI is usually sufficiently fast that there's no point using interrupts between bytes.  When I've used SPI with low-end MCU's, if interrupt handling (entering and leaving an ISR) was more than about half the CPU time required to exchange the byte then I haven't bothered with using an interrupt-driven approach, just done the whole transfer in normal CPU time.